From kde-core-devel Wed Jul 25 12:10:24 2001 From: Simon Hausmann Date: Wed, 25 Jul 2001 12:10:24 +0000 To: kde-core-devel Subject: Re: RFC: KConfig changes for 3.0 X-MARC-Message: https://marc.info/?l=kde-core-devel&m=99606384501753 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