Moving KPrefs from libkdepim to kdelibs

Waldo Bastian bastian at
Tue Jul 22 12:57:06 BST 2003

Hash: SHA1

On Tuesday 22 July 2003 00:41, Ingo Klöcker wrote:
> On Monday 21 July 2003 17:10, Waldo Bastian wrote:
> > 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 :-}
> Did you notice this problem this very minute or why did I never see a
> note nor a patch for this on kmail at or The next
> time please send us a short note instead of pointing with the finger at
> us. You are the KIOSK expert. You can't expect that everyone always
> does it the KIOSK way. But if you don't tell us then we can't learn
> from our errors.

Please don't see this as finger pointing. I mentioned KMail because I got a 
SuSE bug-report about it the other week. I don't expect the KMail developers 
to be aware of such problems or to fix them. I just used it as an example of 
how this particular programming-pattern leads to problems for KIOSK. 

KPrefs should be able to address those problems and KMidentity would be a good 
candidate to be ported over to a KPref based approach which would then solve 
the issue. All in due time.

- -- 
bastian at -=|[ SuSE, The Linux Desktop Experts ]|=- bastian at
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see


More information about the kde-core-devel mailing list