KConfig and KConfigBackEnd patch to allow arbitrary number of config files

[Adam Treat]

On Sunday 09 July 2006 4:19 pm, Thomas Braxton wrote:
> On Sunday 09 July 2006 14:17, Adam Treat wrote:
> > Hey All,
> >
> > The patch allows us add arbitrary number of config files to the global
> > KConfig object in KDevelop...  With this we can have the following config
> > files for a kdevelop4 instance:
> >
> > 1. $KDEINSTALL/share/config/kdeveloprc|kdeglobals
> >
> > 2. $USER/.kde/share/config/kdeveloprc
> >
> > 3. $PROJECTDIR/$PROJECTNAME.kdev4
> >
> > 4. $PROJECTDIR/.kdev4/$PROJECTNAME.kdev4
> >
> > The most specific file would be #3 and #4... depending upon the
> > particular setting we're talking about.
> >
> > This will give us seemless configuration options throughout.  In other
> > words, we can specify per project values for every setting that kdevelop4
> > offers. And if we take special care to make sure hard paths and such go
> > in the hidden directory... we can pass around project files :)
> >
> > Please review the patch carefully.  It works for me when I add calls
> > like...
> >
> > m_config->config()->addFileToMergeStack(
> > "/home/kde/trunk/KDE/kdevelop/global.kdev4" );
> > m_config->config()->addFileToMergeStack(
> > "/home/kde/trunk/KDE/kdevelop/.kdevelop/local.kdev4" );
> >
> > ... in kdevelop's new kdevcmodule.cpp constructor.
> >
> > The idea is to have ONE global configuration dialog that will have
> > different modes depending upon when you open it.  If you open it without
> > a project loaded it will write to #2.  If you open it with a project
> > loaded it will change the top level menu item from 'Configure KDevelop'
> > to 'Configure Project' and will write to #3 and #4.
> >
> > Plugin writers won't have to worry about any of that as it will be done
> > automatically by the kdevelop framework and KConfigXT.  Just write your
> > KDevCModule and you're done.
> >
> > Once committed, I'll go ahead and hook this up to the project loading and
> > we'll be in business :)
> >
> > Adam
>
> Is this idea generic enough to be in kdelibs? Does anyone else want/need
> this functionality? Or would it be a an extension only for kdevelop? If
> it's only for kdevelop, why not just subclass KConfig/KConfigINIBackend in
> the kdevelop sources, and use those for kdevelop's config objects?

Sure.  I can imagine any app that uses project files finding this patch 
helpful.  The problem with subclassing KConfigINIBackEnd is two fold:

1.  Not enough virtuals in KConfigINIBackEnd to do what I want so instead I'd 
have to just copy the class from kdelibs.
2.  Aaron has talked about developing new backends and I don't want kdevelop 
to miss this and I don't want to maintain a copy of INIBackEnd in another 
place.  The whole idea is that we can patch it at the source now.