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

List:       kde-core-devel
Subject:    Re: KConfig object-orientification
From:       Bernd Gehrmann <bernd () physik ! hu-berlin ! de>
Date:       2001-11-01 14:10:01
[Download RAW message or body]

On Thu, 1 Nov 2001, Rik Hemsley wrote:

> #if Bernd Gehrmann
> > On Wed, 31 Oct 2001, Charles Samuels wrote:
> > > 
> > > Well, I've started on the arduous task of making KConfig::group() return a 
> > > temporary class (KConfigGroup) that has all the accessors (like readEntry, 
> > > writeEntry, etc).
> > 
> > IMO, this looks clumsy and overengineered. QSettings has a much more
> > natural API, and it's also more powerful, as it simulates hierarchical
> > groups.
> 
> Well, we could use QSettings... we just need to not care about the fact
> that it stores such a huge amount of duplicate data when you use lots of
> hierarchy, and we would have to provide an extra class which allows
> saving/loading of types we are used to KConfig handling (QPoint, QFont,
> QSize, unsigned int, etc.)

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.

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.

Bernd.

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