Moving KPrefs from libkdepim to kdelibs

[Waldo Bastian]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Monday 21 July 2003 14:14, Cornelius Schumacher wrote:
> A couple of people have asked, if we can move KPrefs from libkdepim to
> kdelibs. It's a class which provides easy access to configuration
> information stored via KConfig in a type-safe way with as few redundant
> code as possible, in particular without specifying config file keys and
> default values at more than one location in the code.

I think this is indeed a welcome addition to KConfig and KAutoConfig that we 
have at the moment. I would like to see the following issues addressed before 
it is moved to kdelibs:

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.

2) It should honour immutability of config keys. KMail's KMIdentity class is a 
good example of a settings wrapper that effectively ignores KIOSK 
restrictions. The KIOSK restrictions work good in situations where one code 
part writes changes to a config file and the other part reads those  changes 
in in order to use them. This way the the code that uses the settings always 
uses settings that have been subjected to the KIOSK restrictions. In 
KMIdentity this breaks because the changes are written to the internal data 
structures themselves and used from their again. The KIOSK restrictions only 
kick in after you exit and restart KMail. That's not what the sysadmin 
ordered :-}

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.

The next best thing is to revert the settings that are immutable once they are 
written to the config file. Although not 100% effective, in most cases the 
settings will be written to the config file directly after any substantial 
change has been made. At this point settings that have been marked immutable 
could be read back from the config file so that any further access to these 
settings will work with the original settings and not the modified ones. 
(That would need to happen in KPrefs::writeConfig() and KPrefsItem should get 
a bool isImmutable() function)

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

3) It should be possible to use a KPrefs based config-backend together with 
KAutoConfig. I would even go as far as saying that KAutoConfig should _only_ 
support KPrefs, and not KConfig directly to promote the use of KPrefs, see 4.

I guess it should be moved to kdelibs in order to do so, otherwise the 
dependencies will be a bit of a problem.

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

Once that is complete the next step should be:
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 :)

Cheers,
Waldo
- -- 
bastian at kde.org -=|[ SuSE, The Linux Desktop Experts ]|=- bastian at suse.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE/HAKBN4pvrENfboIRAsg0AJ9NrMHgBUp6uu7DOgR26I+5+my76gCcCOIx
zQ0p2du9NrGFTNlq24LnWAo=
=cxtz
-----END PGP SIGNATURE-----