RFC: KConfig XT (KDE 3.2)

[Cornelius Schumacher]

On Sunday 16 March 2003 00:07, Waldo Bastian wrote:
> 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 ?

I don't think that this would be possible. KAutoConfig provides a nice 
way to make widget settings persistent, but it doesn't address the 
problem of access of the data by the application code outside the 
preferences dialog which is the main point of KPrefs. In order to have 
config options only defined at one place KAutoConfig would have to 
access KPrefs instead of the config file, but that isn't possible 
because KAutoConfig can't know about the C++ types of the config 
values, so the generic approach using the Qt metadata fails.

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

The second solution is exactly what I had in mind ;-)

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

Agreed. Having documented meta data for the config options cetainly is 
something useful.

-- 
Cornelius Schumacher <schumacher at kde.org>