[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:48:26
[Download RAW message or body]

On Wed, Jul 25, 2001 at 02:33:18PM +0200, Rob Kaper wrote:
> On Wed, Jul 25, 2001 at 02:10:24PM +0200, Simon Hausmann wrote:
> > 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?
> 
> For text entries that might be a problem, although it should be possible to
> have a way to take default out of the namespace, for example by requiring
> actual text strings to be quoted.

Could that possibly break backwards compatibility? :-}
 
> > > 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.
> <snip>
> > IMHO the right fix is not to enrich the kconfig file but to add a proper GUI.
> 
> The problem with that concept is that our configuration GUI's are getting
> overcrowded. I'm not proposing to make a config editor the default, only as
> an add-on where more experienced users can change advanced settings that
> wouldn't make it in the GUI due to overcrowding.

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.

What we actually need for a kconfig editor is the meta information of which
field having which type and some documentation around it (that's an argument
for not putting the description in the kconfig file -> you might want to
translate the description) . Maybe we shouldn't try to put this information
into the config files but into a separate file/database.

Bye,
 Simon

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