RFC: KConfig XT (KDE 3.2)

[Benjamin Meyer]

> Goals
> =====
>
> * 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".

You forget 4) in the settings dialog/widget to start with before the read 
settings function.

> * Provide type-information about config entries to facilate "KConfEdit"
> like tools. Ideally type-information also includes range-information.
>
> * Facilitate the documentation of config entries.
>
>
> Plan A
> ======
>
> Instead of relying on the defaults that are hard-coded in the application,
> rely on default configuration files being installed in $KDEDIR. The
> technical changes required for this are very minimal, it is mostly a change
> in policy.
>
> Type information can be provide by preceding every entry with a formalized
> comment.
>
> Work to be done:
> * KConfig needs to be extended to provide access to the default values
> provided by the default config files. KConfig already stores this
> information internally.
> * A formal comment structure needs to be designed that can convey
> type-information. Preferably in such a way that it is easily parsable by
> both machine and user.
> * KConfig needs to be extended, or another class created, that is able to
> parse the formalized comments.
> * A tool needs to be developed that can assist developers with the
> generation and verification of default configuration files that include
> type-information.
>
> Drawbacks:
> * We rely on default configuration files being properly installed.
>
> Plan B
> ======
>
> There is no plan B.

Hmmm.  Well in working on KAutoConfig I did solve many of these same problems.  
Running down them:
-Default values all over.
I am almost entirly against having a default values file simply because that 
is yet another file that the developer has to create and yet another file 
that has to be parsed on start up.  With KAutoConfig the applications only 
have to have the default values in two spots.  The first spot is the initial 
value of the widget and the second spot is when calling readEntry() in the 
class that utilizes the setting.  KAutoConfig takes care of the hitting the 
Default button automagicly as well as setting up and saving the settings.  
With many apps using designer files this makes life very easy for the 
developer to see the default values.  Thus the managing of the two default 
places pretty easy.

-Provide type-information about config entries to facilate "KConfEdit" like 
tools.
KAutoConfig currently passes QVariant's to KAutoconfig.  This information is 
already there for KConfig to utilize.  The only work involved would be added 
it to the that function in KConfig (maybe just add "// " + qvar->type()).  
KAutoConfig could very easily get range information and send it along too and 
then all applications that use KAutoConfig would automagicly gain that 
ability.

-Facilitate the documentation of config entries.
Hmm I am not really sure what this means.  What does it mean?

-Benjamin Meyer