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

List:       kde-core-devel
Subject:    Re: RFC: KConfig changes for 3.0
From:       Martijn Klingens <mklingens () yahoo ! com>
Date:       2001-07-25 13:19:12
[Download RAW message or body]

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_ ;-)

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.

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.

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

Martijn

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