KDevelop4 UI [was: Want to participate in KDevelop4 development]

Andreas Pakulat apaku at gmx.de
Thu Sep 27 19:00:10 UTC 2007


On 27.09.07 23:27:24, Mohammad Bhuyan wrote:
> On 9/24/07, Andreas Pakulat <apaku at gmx.de> wrote:
> > On 24.09.07 11:55:55, Mohammad Bhuyan wrote:
> > > IDEs like VisualStudio has a nice approach of having a "Solution" to
> > > contain/manage multiple projects. I find it very intuitive for
> > > developers to go with the
> > >
> > > concept of a "Solution" contains "Projects" and all of the are managed
> > > through "Solution Explorer". What is the vision of Kdevelop4 regarding
> > > this?
> >
> > So far we're aiming for a loosely coupled list of projects, not stored
> > into a separate file. IMHO the list of opened projects should just be a
> > list of url's of the .kdev4 files. If a project then depends on another
> > project that should be expressed by a configuration item in that
> > projects .kdev4 file, naming the projectname of the other project (not
> > the .kdev4 file). This is not implemented yet.
> >
> 
> My thinking was, having the "solution" (anybody want to coin a term
> here?) concept hence a file to represent the solution will have to
> contain more than a list of .kdev4 file urls.
> 
> While I agree that inter project dependency metadata can be contained
> in the individual project files, but there are few properties of
> solution that things that should be provided at the "solution" level.
> Like,
> 
> The build configuration (Debug/Release) which either applies to all
> the project within the solution or through an option at solution level
> to let the individual project configuration to take precedence.

As Kris already said that doesn't really exist with our buildsystems.
For CMake its possible to just have 2 builddirs with debug or release
configuration and easily switch between those using the cmake
configuration. This however doesn't work for autotools or qmake
buildsystems, neither of those can clearly separate builddir and
srcdir and none of the two have a really easy way to switch between
builds.

> Version control of the solution (with its projects) as an entity.

Its fairly easy to select a handful of projects and commit them using
the project management view :)

> Checkin/Checkout solution rather than individual project basis. Of
> course with the provision where projects within a solution can reside
> a different source repository than the solution file itself.

Projects may even have different version control systems, but with the
KDevelop4 VCS architecture that shouldn't be much of a problem. We could
even have a dialog popping up if the user commits 1 file/project asking
wether he also wants to commit any changes in related projects.

There's one thing with the solution though: What happens if a project is
part of two solutions? Where do we group that project, do we put it into
both solutions (storing-wise of course, but also visually)? I'm not sure
if our view's can handle the same item popping up at different places in
a tree (and a copy would make things much harder/memory consuming).

> This two being from top of my head along with the fact that it has to
> be future proof (yes yes, never happens but we try!) I would think
> that we need to carefully define the "solution file" rather than
> thinking of it as a flat list of kdev4 URLs.

Well, its not just a flat list of kdev4 urls, thats the "last opened
projects" list. Maybe we could integrate the solution-idea with David's
working-sets idea, but instead of files some working-sets have projects
in it (and everything you do to the working-set, like doing and svn
action) happens to 
 
> > > (3) Output
> > >
> >
> > > - Click code to jump to help file / Internet location
> >
> > Huh? How do you mean that, can you elaborate a bit please?
> >
> 
> Clicking error/warning number (code) takes to corresponding the help
> file or internet location (TechBase??)

As Kris already said, thats close to impossible. I could imagine
something like "search this in browser" action in a context menu. That
would need selection of parts of the output lines though (which AFAIK is
not really easy to do)

Andreas

-- 
Do not sleep in a eucalyptus tree tonight.




More information about the KDevelop-devel mailing list