Merging settings by group in KConfig

[Matt Rogers]

On Mon, Apr 03, 2006 at 10:27:27AM -0600, Aaron J. Seigo wrote:
> On Monday 03 April 2006 09:49, Matt Rogers wrote:
> > On Mon, Apr 03, 2006 at 08:27:33AM -0600, Aaron J. Seigo wrote:
> > > do these defaults need to be dynamic? or could this be accomplished by
> > > extending KConfigXT to be "settings group aware"?
> >
> > Yes, the defaults need to be dynamic but I'm not sure what you mean by
> > "settings group aware".
> 
> right now KConfigXT doesn't really have the concept of "this group of 
> configuration elements constitutes an aggregate of settings which may be 
> instantiated zero or more times in the config file"
> 
> some of the needed support is there, such as dynamic names for groups and 
> items based on parameters, such this example from kmail:
> 
> 	<group name="KMMessage #$(langId)">
> 
> where langId is passed into the ctor:
> 
>   <kcfgfile name="kmailrc">
>     <parameter name="langId" />
>   </kcfgfile>
> 
> this isn't very convenient for many typical use cases where one would have to 
> instantiate a config object for each and every group, and it's not a 
> well-known feature of kconfigxt, either.
> 
> > My vision was being able to have a KConfig file 
> > that looked like:
> >
> > [Chatwindow][$d]
> > Key1=Value1
> > Key2=Value2
> > OverriddenKey=Default
> >
> > the "[$d]" specifies Defaults, similar to "[$i]" for immutable.
> > When the user changes the appropriate setting, this gets
> > written to the local KConfig file:
> >
> > [Chatwindow:FooContact]
> > OverriddenKey=NotDefault
> 
> the question really is where does the code (and resulting overhead) belong: in 
> KConfig itself or in the KConfigXT tools?
> 
> personally i'd prefer to see this go into KConfigXT to keep KConfig from 
> getting overly complex (haha). it would also help encourage people to use 
> KConfigXT, though we certainly need more up-to-date documentation on 
> KConfigXT at this point in time.
> 
> it also seems to me more natural to provide this in KConfigXT since that 
> already has the concept of describing and documenting the semantics of config 
> files versus KConfig which is primarily about storage and retrieval.
> 

I fail to see how KConfigXT has anything to do with this other than
helping to create the dialog that will edit the default settings but I
may not understand exactly what KConfigXT is fully capable of either,
since I've never used it.

> what sort of API did you have in mind?
> 

setGroup( const QString& realGroupName,
          const QString& defaultGroupName = QString() );

At least for Kopete, we'll (eventually, when the code that i'm working
on that spawned this discussion goes into SVN to fix several bugs) know
what the various group names will be. So for the particular purpose i
need it for and continuing the above example, i'd have the following code:

//Get the config object
KConfig* config = KGlobal::config();

//Set the group. other stuff would be here to determine the real group
//name to use
config->setGroup( "Chatwindow:FooContact", "Chatwindow" );

//read an entry. if no entry for the key exists in the real group
//read the entry from the default group, and if no entry exists there
//use the specified default.
config->readEntry("OverriddenKey", "Default"); //returns "NotDefault"

--
Matt