KDevelop4 project file

[Jens Dagerbo]

Sounds like great stuff, Adam. Having One API for settings is an
obvious improvement! Thanks  for writing down this explanation too.

A few thoughts:

The only immediate drawback I can see when going from XML to INI-style
storage is the mess the latter makes of hierchical data. (And we have
that type of data - the breakpoints, bookmarks and open file lists
comes to mind, I'm sure there is more.) Do you have any thoughts about
this? KDE3 KConfig didn't do this very nicely, have things changed in
KDE4 or do we need to extend the API ourselves?

Also:
>         KDevConfig::standard() <-- This is the usual way you will access it.  Only in
>         very rare cases will you need to access it from the other two methods.
>
>         KDevConfig::localProject() <-- If you are making a setting without KConfigXT
>         and wish to make sure the setting is NOT saved in the global shareable
>         project file, then you can use this.

Looking at a KDev3 .kdevelop file I find that almost all settings are
in fact local and not shareable. Or maybe "shareable" is the wrong
word.. if a setting goes into the shared project file it is not
shareable, it is _enforced_. How many settings actually makes sense
like that? Very few.

Having different AStyle settings for different projects is of course
how things should always have been, but making an AStyle setting
change made by one developer saved to the shared project file and thus
imposed upon all users is clearly not what we want. (Imagine using
KDevelop on a large legacy project with different code modules using
different coding standards.) I know AStyle was just an example but it
is the first thing to come to mind where it _might_ make sense to have
a shared setting but this should be policy, not enforced by KDevelop.


// jens