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

[Kris Wong]

My thoughts on some of these issues:

> > 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.
> >

What would be the nature of these relationships?  Would building a dependent project automagically build all its depenedencies first?  Would the project file have absolute paths to its dependent project files?  This would likely prevent version control of the project files (a big weakness in kdevelop 3).  The concept a "solution" file is handy here.

>
> 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.

KDevelop does not have the concept of build configurations.  This would be dependent on the build system being used, and is a much more difficult concept to employ on *nix than in windows.

> > > (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??)
>

Clicking on an error or warning takes you to the specified file and line #.  The error/warning number itself would be dependent on the compiler being used (gcc, intel, etc...) and we have absolutely no knowledge of this.  Not to mention we would have no control over any documentation that may or may not exist.

Kris Wong