Moving KPrefs from libkdepim to kdelibs

Josef Weidendorfer Josef.Weidendorfer at
Tue Jul 22 18:31:06 BST 2003

On Tuesday 22 July 2003 14:10, Benjamin Meyer wrote:
> Hash: SHA1
> On Monday 21 July 2003 6:54 pm, Ingo Klöcker wrote:
> > On Monday 21 July 2003 18:26, Benjamin Meyer wrote:
> > > On Monday 21 July 2003 11:10 am, Waldo Bastian wrote:
> > > > 3) It should be possible to use a KPrefs based config-backend
> > > > together with KAutoConfig. I would even go as far as saying that
> > > > KAutoConfig should _only_ support KPrefs, and not KConfig directly
> > > > to promote the use of KPrefs, see 4.
> > [...]
> > obviously the application's global config file can't contain any
> > default values for an uncountable number of accounts, transports,
> > identities, etc..
> I think you are confusing the applications global config with the kdeglobal
> config.  An applciation can not modify its global config, but it can modify
> the kdeglobal config.  Or put it this way: If you can't do it in the
> applications global config how do the kmail developers currently do it in
> the binary?  The user accounts etc are stored in their local configs, not
> the binary or global config.


I suppose he thinks about cases where config keys are before (or contain 
potentially unlimited numbers). Take my case with KCachegrind:

I store GUI layout depending on the some attribute from loaded files (the 
command names from which profiles are done). So the user can have
a different layout for e.g. profiles from commands "ls" and "true". I store 
these in KCachegrinds default config file.
So I have
	Layout-true = Bar.

How can an administrator put any default values for keys into a global file,
where the key isn't known in advance?
The correct way would be the introduce a config-key inheritance tree for 
default values.

I.e. somewhere there should be the information that e.g. keys "Layout-*" take
their default from a key "DefaultLayout". This can be done implicit, but
there has to be a way in KAutoConfig to specify this...

Perhaps I'm totally wrong here, but I think this is at least a problem ATM.


More information about the kde-core-devel mailing list