Moving KPrefs from libkdepim to kdelibs

[Cornelius Schumacher]

On Monday 21 July 2003 17:10, Waldo Bastian wrote:
>
> 1) KPrefs::setDefaults() reverts to the default hard-coded in the
> application. As Benjamin pointed out in the "KConfig Bug" thread last
> month, the "Use Defaults" button in the KDE GUI should revert to the
> system-wide defaults provided by the system-admin, not to the
> application default. This needs fixing throughout KDE, see kcmkonsole
> for an example how to do it easy.

Ok. What exactly is the "system-wide" default, by the way? The first 
file in the config file chain, or the last one not writable by the 
user, or the last one outside KDEHOME or something completely 
different?

> Taking koprefs as an example: Ideally you would want to make
> mTimeZone a read-only variable if the corresponding configuration
> entry had been marked as immutable. That's not possible
> unfortunately. It would be possible if you defined accessor-functions
> for every variable like is done for mName and mEmail but that would
> lead to an explosion of functions.

I think we can't go without accessor functions if we want to have a 
clean solution to that problem. The problem of explosion of functions 
can be solved by autogenerating subclasses of KPrefs by something like 
a "config compiler" (see your point 4.).

> In addition to this it would also be essential to have a function
> available to check whether a setting is immutable or not. This way
> code that uses the settings can decide not to offer certain
> functionality at all in the first place. E.g. in the case of KMail,
> KMail could check if the identity-settings where immutable and if so,
> it could decide to not offer the "Add Identity" and "Remove Identity"
> buttons. (For that KPrefs should get a function to query whether a
> KprefsItem is immutable. using what as key? T &reference?)

For this I would also like to have an auto-generated function based on 
the name of the config option. So e.g. for a time zone setting we would 
get a "timeZone()" accessor function and a "timeZoneIsMutable()" 
function to check, if the option is immutable or not.

For generic access via the KPrefsItems we would of course also need 
something like "KPrefsItem::isMutable()".

> 3b) Reconsider the naming of KAutoConfig and KPrefs to better reflect
> the fact that KConfig, KAutoConfig and KPrefs are related and to
> better stress the individual function of each. KPrefs -> KConfigStub,
> KAutoConfig -> KConfigGUI ??

I have no strong preferences here. What do others think?

> 4) Auto-generation of KOPref like classes from a
> configuration-description file. A bit like dcopidl. (I secretly hope
> that Oswald wants to do this because my yacc-skills are rubbish :)

Why do you think this should be done with yacc?

-- 
Cornelius Schumacher <schumacher at kde.org>