[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: Moving KPrefs from libkdepim to kdelibs
From:       Benjamin Meyer <ben () meyerhome ! net>
Date:       2003-07-21 16:26:59
[Download RAW message or body]

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

On Monday 21 July 2003 11:10 am, Waldo Bastian wrote:
> 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.

Any app that uses KAutoConfig/KAutoConfigDialog exclusively is now fixed I am 
happy to say :)

> 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 :-}

This is actually one area where KAutoConfigDialog shines.  If something is 
marked immutable when the user pulls up the config dialog KAutoConfigDialog 
will automaticly disable any widgets that are marked immutable, thus 
preventing changes internally let alone at the config level.  For entries 
that the user can only modify during run time via the configure dialog the 
problem is solved.  Because of that only entries that can be modified at run 
time not outside the scope of KAutoConfigDialog such as widgets in the 
mainwindow the developer would need to check and disable it ( or use 
KAutoConfig on it :-D )

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

Take a look at KAudioCreator which allows you to add encoders and uses 
KAutoConfigDialog sub dialogs which if you are not allowed to add encoders 
(the next empty encoder in the config is marked immutable and is empty) then 
when the dialog pulls up all of the widgets are disabled and the user can't 
add a new encoder.  This sounds like a very similar problem to what you are 
describing above.

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

Please correct me if I am wrong (I haven't looked at KPref's code sense March) 
but KPrefs main reason for being was it set _one_ place for the default 
values.  If I were to move all of my default values for an application to my 
applications global config and remove them all from the binary I could 
achieve the same result.  Any time I needed a entry I could just call 
config->readEntry("foo") without the default value because I knew that the 
default value was in the global list.  Even KAutoConfig would continue to 
work just fine.  The the major feature of KPref was that you stored all of 
the keys names in one place, but you can do that right now with just a header 
filled with defines.  I see no reason why KAutoConfig can't be extended to 
utilize KPrefs, but for the majority of apps I see no reason why you would 
want to.  I don't see anything (currently) that KPrefs adds in value above 
KConfig for KAutoConfig to use that would benefit the developers.  Again 
please correct me if I am wrong about KPref.

- -Benjamin Meyer

- -- 
Public Key: http://www.csh.rit.edu/~benjamin/public_key.asc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE/HBRT1rZ3LTw38vIRArN5AJwP2nr631UwFmcAg1fMO6jEGaGXPQCgjowa
h/VeifW9XCrGwInI1MDnv+8=
=f9cD
-----END PGP SIGNATURE-----

[prev in list] [next in list] [prev in thread] [next in thread]