On Wed, Jul 25, 2001 at 03:19:12PM +0200, Martijn Klingens wrote:
> On Wednesday 25 July 2001 14:48, Simon Hausmann wrote:
> > Ohh, right. I see your point now. Hm hm. There's one disadvantage with
> > always writing out configuration values: They get written into the local
> > config and if you do that for each and every entry you
> >
> >  a) get full blown config files in the user directory, containing redundant
> >     information
> >
> >  b) loose the ability for a system administrator to change global values,
> >     because the global changes never get applied to the apps as for each
> >     field there is an entry in the local file.
> 
> Well... We have both these problems already, as soon as you change some 
> settings most apps write _all_ settings and not just the changed settings. 
> This is current tense, this is _now_ ;-)

But that's after the user decided to customize the configuration, it's not
done by default.
 
> What we need is a way like Rob proposes to set each and every configurable 
> value to "use default" so it cascades up the chain until it is defined 
> explicitly somewhere (ultimately the default in the C++ code). _Only_ if a 
> user changes a value it will be set to a 'real' value, and the user also 
> needs a way to revert back to the sysadmin's default. That is, not to the 
> same value, but to the sysadmin's value, so if the admin changes the default, 
> the user's config immediately picks up the change.

Reverting back should IMHO be done by providing a 'default' button in the
GUI (in the app or in a kconfig editor) , which deletes the local entry.
 
> We do introduce two new problems here, though, but those are solveable, I'm 
> sure:
> 
> 1. Like you said we must make sure compatibility isn't affected. Probably we 
> need to extend the API and have to live with the fact that old apps don't use 
> this. Mark the old method as deprecated and remove it in KDE 4.0. Or even 
> remove it now unless we #define KDE_2_SOURCE_COMPAT somewhere or so... Just 
> some thoguhts.

I was less thinking in terms of the C++ API but rather in terms of the actual
config file format.
 
> 2. It will put some strain on GUI design to allow a user to switch back to 
> the default. Listboxes, radio buttons and similar controls can be extended 
> with an extra option and checkboxes can be made tristate, but for other 
> widgets we have a challenge to solve :-)

Yes :)

Bye,
 Simon