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

List:       kde-core-devel
Subject:    KPrefs status
From:       Cornelius Schumacher <schumacher () kde ! org>
Date:       2003-07-31 22:45:14
[Download RAW message or body]

A couple of days ago I asked for opinions about moving KPrefs from 
libkdepim to kdelibs. Considering the feedback I did some work on this 
and some related classes. The current status is:

- Defaults are read from global config files if present. If no global 
config files exist, hard-coded "factory defaults" are taken.
- The config file is re-read after writing. This way immutable settings 
are reflected in the KPrefs object. There still is a problem in the 
GUI. The widgets will be reset to the immutable default, if they are 
changed by the user, but the application will only see the immutable 
value.
- I added cfgc, the configuration compiler, which creates KPrefs 
subclasses from configuration-description files. It uses an XML 
description and convert this into C++ code. Source code and DTD can be 
found at kdepim/libkdepim/cfgc.
- KOrganizer has been ported to make use of cfgc for most of its config 
options. This significantly simplifies the code.
- I also added some code to KPrefsDialog from libkdepim to autogenerate 
a configuration dialog GUI from the config information got from KPrefs. 
There is an example configuration description and dialog in 
kdepim/libkdepim/cfgc. Use "make check" to build it.
- Integration with KAutoConfig hasn't started yet, but this probably 
will not a big problem. I think KPrefs and KAutoConfig nicely 
complement each other.
- KPrefs is still missing support for providing access to the mutability 
status, but that's almost trivial to add. When this is done the 
automatically generated GUI will also get support for that and manually 
created dialogs will have easy access to this information.

All this is still work in progress, in particular the autogeneration of 
preferences dialogs, and it will certainly need some additions to the 
KPrefs API to support all what we need. I will be on holiday for the 
next two weeks, so I would like to postpone the move to kdelibs for a 
while, but I'm quite confident that this will become a solution useful 
for many applications.

-- 
Cornelius Schumacher <schumacher@kde.org>
[prev in list] [next in list] [prev in thread] [next in thread]