RFC: KConfig XT (KDE 3.2)

Cornelius Schumacher schumacher at kde.org
Sat Mar 15 18:32:13 GMT 2003

On Saturday 15 March 2003 16:38, Waldo Bastian wrote:
> * Have the default value for config entries defined in 1 place.
> Currently it is not uncommon to have them defined in three places:
>   1) In the application that reads the setting in order to use it
>   2) In the settings dialog when reading the setting
>   3) In the settings dialog when selecting "Use defaults".

One solution to that problem is in libkdepim/kprefs.{h,cpp} and derived 
classes. It also solves the problem of having to know the type of the 
config value at different places in the code.

> * Provide type-information about config entries to facilate
> "KConfEdit" like tools. Ideally type-information also includes
> range-information.
> * Facilitate the documentation of config entries.

It might be a good idea to not try to achieve all three goals by a 
single config file. There are quite different requirements from the 
side of the application.
- The default value has to be known by the application but it might make 
sense to store this externally.
- The type already is known and defined by the application. To store 
this at another location duplicates this information which might lead 
to inconsistencies.
- The documentation of config entries is something which in most cases 
isn't relevant to the application.  Having to parse documentation for 
config entries in 40 languages in order to get a default value doesn't 
sound very attractive.

I still think that the best solution for these and some other config 
related problems would be to autogenerate the C++ code accessing the 
configurations from a single meta description of the config options. 
This would allow to have a single definition of config options and 
attributes and to have the most efficient way to access these options 
depending on what happens with the information.

Sidenote: We shouldn't forget that providing meta data for config 
options and also a config file editor would only be relevant to a small 
fraction of expert users and doesn't relieves us from improving the 
configuration dialogs and the control center.

Cornelius Schumacher <schumacher at kde.org>

More information about the kde-core-devel mailing list