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

[Andreas Pakulat]

On 27.09.07 10:29:16, Kris Wong wrote:
> 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?

That would be a possibility, either a kdevelop-wide option, or a dialog
thats asking it (of course with a don't ask again option). On that note:
I wonder wether kde4 already has a way of re-enabling these questions, I
think not but IMHO it should...

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

No, each project would have a list of project _names_ as dependecies.
Then the projectmanager can map these names to actual projects that are
open. So you'd need to have the dependecies open in KDevelop to have all
the inter-project-dep-stuff working, OTOH it should of course be
possible to just checkout the kdevelop module, without the need to also
checkout kdelibs just to build it ;)

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

With CMake its relatively easy already, just switching a combobox
selection in a config widget. But we shouldn't restrict project deps to
the same buildsystem and for QMake it needs a considerable amount of
setup to have fully separated builds. But a GUI switch would mean the
QMake Manager has to write into "sophisticated" qmake files which I want
to avoid at all costs ;) So I agree in the general case.

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

As said in my other mail: a way to easily let Google (insert your
favourite search engine) find an error should be quite helpful already.

It seems our new contributor comes from a MSVC/win32 background, where
things are _much_ easier, due to all its limitations.

Andreas

-- 
If you think last Tuesday was a drag, wait till you see what happens tomorrow!