RFC: KConfig XT (KDE 3.2)

[Benjamin Meyer]

On Saturday 15 March 2003 6:32 pm, 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.

Wow!  Yet another configuration helper class. :-D  The other one is the lib in 
kmines that is used in several games.  It generates the config's from an xml 
file.  Unfortunetely it falls victim to the problem that it is hard to 
improve the ui of the settings dialog from what is generated.  The lib is 
used in several games (you can probably guess which ones, they all look 
alike).  I guess I wasn't the only one pondering how to fix this problem.  I 
completely re-wrote the KAutoConfig class I believe 4 times over the course 
of a few months (unhappy with the first three) before we have what it is now.

After looking at KPrefs I like what it does, but don't think it is needed 
because of what KAutoConfig does and how it integrates into an application.  
As I have been converting applications I have found that in general in a 
window/widget you will have a readSettings() function which will directly 
call readConfig() for the 10 or so settings that are read for that widget.  
That is all that the programmer has to do.  The setting of defaults, reading, 
writing, immutability, is automaticly handled by KAutoConfig.  Thus creating 
a kpref's class would be kind of silly sense it would only used once.

At some point in the future I was hoping to convert all of the apps that use 
the lib in kdegames (and perhaps the apps that use the kpref class too?), but 
I hadn't approached the authors for permission yet because I know that the 
authors has invested both effort, time and emotion into the class and I 
wanted to have a large number of applications already using it to demonstrate 
it working, how it works, and why it is so nice.

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

I could add a function to KAutoConfig which will force the output of all of 
the default settings to a file.  This function could be called via dcop or 
something and so if for example a kiosk admin wanted to make a special 
settings file he/she could use dcop to spit out all of the default settings 
for examination.  The admin could then modify the default config on the 
system (non user writable located in /etc/kde?) and insert any special 
default settings they want.  This way developers don't have to maintain a 
default settings file, power users get more fun, and the config files still 
don't grow in size (but shrink as I clean up core libs!), kconfig doesn't 
have to parse extra files, every app that uses kautoconfig would automaticly 
get this feature, kiosk admins get the new functionality without any 
sacrifices by the general user base... hmm this is sounding like a really 
good idea.

> - The type already is known and defined by the application. To store
> this at another location duplicates this information which might lead
> to inconsistencies.

Agreed, it should be automatic such as with QVariant->type()

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

100% agree.  Besides most settings already are pretty self documenting such as  
[Game]
ship_speed=10

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

See my comments above.  It is just too hard to create a clean ui from xml and 
it is so much easier/faster (both in execute and development) to have a ui 
file.

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

Yah I would have to agree.  Almost a priority type thing, effort vs reward 
etc.  Would the only benefit of adding the meta data be the regedit app?

-Benjamin Meyer