Moving KPrefs from libkdepim to kdelibs

[Benjamin Meyer]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tuesday 22 July 2003 1:31 pm, Josef Weidendorfer wrote:
> On Tuesday 22 July 2003 14:10, Benjamin Meyer wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > 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.
>
> Hi,
>
> 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-ls=Foo
> and
> 	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?

Although it is a bit of a hassle it can be done currently.  The simplest 
solution is that there would be a default value for "Layout" and it would be 
used for any use entry "Layout-*".  So just like normal config read in's when 
someone wants to add a new command you would read in the defaults and simply 
store them into the correct sub group.

> The correct way would be the introduce a config-key inheritance tree for
> default values.

If you are refuring to files we have one, if you are refuring to groups we 
don't.

> 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...
>
> Hmmm...
> Perhaps I'm totally wrong here, but I think this is at least a problem ATM.

More along the lines of an anoyance.  I could add a function to KAutoConfig:

void getDefaultValuesFromGroup(const QString &group);

- -Benjamin Meyer

- -- 
Public Key: http://www.csh.rit.edu/~benjamin/public_key.asc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE/Hoof1rZ3LTw38vIRAu76AJoDkUge+l0D8DqResOuL2HetUXa0ACfQ5Kv
3CDYQpfC5wzcBZc9VSXN00Y=
=gVhQ
-----END PGP SIGNATURE-----