KConfig and KConfigBackEnd patch to allow arbitrary number of config files

[Thomas Braxton]

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?

Thomas