Merging settings by group in KConfig

[Aaron J. Seigo]

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.

what sort of API did you have in mind?

-- 
Aaron J. Seigo
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

Full time KDE developer sponsored by Trolltech (http://www.trolltech.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20060403/f1158ed3/attachment.sig>