[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 12:10:24
[Download RAW message or body]

On Wed, Jul 25, 2001 at 02:02:23PM +0200, Rob Kaper wrote:
> Hello,
> 
> Please give some input on the following idea. For KConfig in 3.0 I would
> like to see the following changes:
> 
> - allow "default" as readable value even for boolean entries etcetera,

Ah, as alternative to simply removing the key? Hmm, but doesn't this ask
for conflicts? What if an application really wants to store 'default' as
value for a certain key?

> - add a "requirement" or good-practice recommendation that applications
>   always save all possible entries in the config file, even those that are
>   default
> - add a description QString to each key and group
> 
> That way, users can be assured there are no "hidden" options in the code
> ever. Every configurable option will be in the configuration file.

I don't think we should encourage users to edit kconfig files manually in
the first place (there's a reason why we put stuff in .kde and not kdegohere-
andedityourstuff :-) . It's a fallback if something is horribly broken, but in 
general the applications are supposed to provide a proper GUI for all their
configuration keys, IMHO.
 
> My concerns regarding this come forth from the removal of "Fade out applet
> handles" from kcmkicker. Since it has no GUI entry and is not present in the
> default saved configuration file, there is no way to know whether the option
> exists but to be familiar with the code.

IMHO the right fix is not to enrich the kconfig file but to add a proper GUI.
 
Just my $0.02 cents

Bye,
 Simon

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