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