RFC: KConfig XT (KDE 3.2)

[Waldo Bastian]

On Saturday 15 March 2003 19:32, Cornelius Schumacher wrote:
> 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.

Oh, that looks nice as well. Do you think it could be combined/interfaced with 
kdecore/kautoconfig.cpp ?

> > * 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.

Yes, I also don't think that having translations in a config file will make it 
very easy for humans to process the info. With 40 translations it means that 
you have 39 lines of garbage for every line or interest. Probably better to 
keep tranlations in a seperate file, if at all. 

> 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.

Yes, that's indeed a good idea. I think we can combine things here though, we 
could use an annotated default configuration file (without translations) as 
the single meta description. Or we could use a seperate meta description 
format and generate a default configuration file from that. (In case we have 
info in the meta description that we only need for code generation.)

> 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.

No, certainly not. It's just that the KIOSK features are quite popular with 
sysadmins and one of the first questions is usually "where can I find 
documentation about the config options". These people certainly qualify as a 
small fraction of expert users, but are nevertheless a very important 
category IMHO.

Cheers,
Waldo
-- 
bastian at kde.org -=|[ SuSE, The Linux Desktop Experts ]|=- bastian at suse.com