KDevelop4 project file

[Adam Treat]

On Thursday 20 July 2006 10:49 am, you wrote:
> 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?

Yah, we talked about this.  AFAIK, as bad as INI is about heirarchical data, 
it can still do it, albeit ugly ;)  Of course, the way to change this would 
be to develop a KConfigXMLBackend for kdecore and a corresponding API for 
KConfig specifying certain config files should use this or that backend.... 
something that could be done, but no one has :)

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

I don't think this is the case.  Yes, many are not shareable, but these are 
all going to be paths and environment variables basically.  Which build 
importer is going in the global file.  Which primary language is going in the 
global file.  What plugins to load can go in the global file.  Lots and lots 
of stuff can go in the global file...

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

Ok, so then don't save any AStyle settings to the project file for whatever 
particular project ;)  There is _NO_ one saying that every setting has to be 
overridden in the global project file.  Let me illustrate:

Say KDevelop defines a default setting for AStyle in the actual AStyle plugin.  
This could either be in code or via $KDEINSTALL/share/config/kdeveloprc.  
Now, say a particular developer doesn't like that AStyle setting.  He could 
simply start kdevelop (WITHOUT A PROJECT LOADED) load 
the 'configure->kdevelop' dialog and have his way with the AStyle settings.  
This would then be saved to $USER/.kde4/share/config/kdeveloprc and will be 
the default for that developer on his/her machine.

Now, say a project manager has decided that AStyle settings shouldn't be 
defined by the project ie, let each and every developer choose for 
him/herself.  All the project manager has to do is decline to touch the 
AStyle settings dialog when a project is loaded :)  See how easy?

However, say a project manager HAS decided that AStyle settings should be 
enforced for a project.  All he/she has to do is load the AStyle dialog when 
the project is loaded and have his/her way ;)  See how easy?

The point is that this is the best of all worlds.  What goes in the project 
file(s) is up to the project manager.  

That is all ;)

Cheers,

Adam

PS And we *could* even provide a 'lockdown' mode where the global project is 
not editable by developers by honoring a 'lock' flag in the project file.  A 
project manager could place the 'lock' flag in the project file by editing it 
manually.  Of course, the developer could hand edit the file and remove 
the 'lock', but ... I hope you get the idea.