[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: Simon Hausmann <hausmann () kde ! org>
Date: 2001-07-25 14:02:44
[Download RAW message or body]
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
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic