[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: KConfig object-orientification
From:       Rik Hemsley <rik () kde ! org>
Date:       2001-11-01 15:39:32
[Download RAW message or body]

#if Bernd Gehrmann
 
> I did not mean to use the QSettings implementation, but its use
> of unix path like keys, which is standard practice not only
> in QSettings, but also in the Windows registry, and in GConf.
> So it would also make it easier to port Qt applications to
> KDE. It makes it also easier to grep for certain keys, which
> I find quite important since configuration keys are documented
> nowhere.

Ah, I see what you mean.
 
> Another thing we eventually will need is a notification signal
> when values have changed. If keys are path-like, this can have
> a simple syntax like
> 
>   config.notify("/mygroup/mykey", this, SLOT(mykeyChanged()));
> 
> A natural extension to this is to get a notification if any
> key in a group or changes:
> 
>   config.notify("/mygroup/mysubgroup/*", ...);
> 
> Please don't make it more difficult than necessary to implement
> such things by extending an inappropriate concept of groups.

That sounds good.

One thing that wastes a lot of development time is the handling of
defaults. Static initialisation is the problem. Damn C++.

My current thinking is that to avoid having to write a special
class for each project, to handle setting defaults, the config
stuff may be able to handle most of the work itself.

Example:

At app startup / library load / whatever, do this:

config.addDefault("/mygroup/mykey", QFont("helvetica", 12));

But then you need a million overloaded methods to handle all the common
data types, another load of methods to return the correct type...
QVariant is one possibility, but then the user code gets nasty, and you
still don't handle user-defined types...

Time to switch language ;)

Rik

[prev in list] [next in list] [prev in thread] [next in thread]