Moving KPrefs from libkdepim to kdelibs

[Waldo Bastian]

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

On Tuesday 22 July 2003 00:39, Cornelius Schumacher wrote:
> 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?

- From the user perspective you have the one in $KDEHOME that gets modified (The 
one that locateLocal() returns) and all the others (see 
KStandardDirs::findAllResources) contribute to the system default. Whether 
those defaults are indeed system-wide or e.g. group-wide depend on how the 
administrator/distributor sets $KDEDIRS for its users.

I believe that the SuSE packages read system defaults from 
/etc/opt/kde/share/config and /opt/kde/kde/share/config

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

If people don't mind going through accessor functions each time then that 
would work indeed. I guess the overhead can be limited by making them inline.

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

It seems fashionable to use that for parsers.

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/HRXAN4pvrENfboIRAgEUAJ4stulZ1ikLBrIopnS70KOvPmaeRgCgmZwI
CSB3xdv6gzx1dfCMI8RHqPw=
=BBWT
-----END PGP SIGNATURE-----