RFC: KConfig XT (KDE 3.2)

[Benjamin Meyer]

On Wednesday 19 March 2003 11:55 am, Oswald Buddenhagen wrote:
> On Wed, Mar 19, 2003 at 08:14:48AM +0000, Benjamin Meyer wrote:
> > On Wednesday 19 March 2003 12:51 am, Oswald Buddenhagen wrote:
> > > On Tue, Mar 18, 2003 at 01:36:51PM -0500, Benjamin Meyer wrote:
> > > > Rather then storing all of the data in one place like KPrefs or
> > > > KAutoConfig I propose breaking it up a bit and putting the
> > > > different components where they best fit.
> > >
> > > that's ugly. even though no information (except a unique key id) is
> > > duplicated, you still have to keep the parts consistent across
> > > several locations.
> >
> > Excuse me? And stuffing everything together in 1 class while also
> > managing it everywhere else is more "elegant"?  I do not see where I
> > would have to keep anything "consistent" in several locations.
>
> it's not about stuffing everything into one class (even though such an
> implementation is more or less self-evident), but about having the
> entire definition of a config entry at one place. that includes the
> group/key name, default, type, further validity constraints (range,
> string type, etc.), description (tooltip), short description (gui label)
> and whatever one might want to. currently (and with your proposal) all
> this data is spread across the code, so maintaining it is generally a
> bit harder and inconsistencies arise from time to time. with the
> proposed centralized definition the config entry the entire "management"
> part is put into kconfig; the code actually using it only references it
> (and this access can be more or less automatically validated).

What about settings that don't have a gui componant?  What about gui widgets 
that don't have text accociated with them? (textinput for example).  When you 
bring up the settings would you link every widget and then when it is closed 
set all the pointers to null?  The reason I spread out the code is a sound 
one.  For example with KAutoConfig the "feature" of the class is that it has 
the ability to parse through a widget tree and understand what is a setting 
and what isn't.  KConfigBase deals with storing/reteriving the values of the 
settings.  Trying to mesh them all together would not be a good idea and 
would cause a lot of extra work.  Even currently how KAutoConfig manages the 
default values is probably not the best way.  Range validation only has to be 
done at one points which is the gui settings dialog.  In fact I know many 
developer who count on that fact to stress test their applciation by hand 
tweaking the settings beyond the limits.  There shouldn't be a need to check 
the input when reading in the values for the only people who would hand edit 
the config understand that they are doing it and that it might break the 
application.  I do not see how mainting the code is harder my way.  If 
anything with a class that holds a bunch of pointers I see the possiblity for 
segfaults occuring.  Each componant should be small and good at what it does.  
Then it is moduler and re-usable.

> > > one could even say that this is worse than the current situation, as
> > > the the default is defined at a place unrelated to the definition of
> > > the config key itself (currently simply the read*Entry invocation in
> > > the main program, which is more or less authoritative).
> >
> > Hmmmm  insert("Key", defaultValue) sure doesn't looks like key is
> > unrelated to defaultValue to me.
>
> the problem is, that all of these new approaches move the location of
> the "authoritative definition" away from the read*Entry in the main
> program, so this can be generally considered bad. this downside has to
> be outweighted by strong advantages, and your suggestion could be
> considered a not big enough improvement to justify the change.

I have yet to hear you suggest a solution that doesn't encapsilate it away 
from the developer.  But you are right my suggestion might not be a big 
enough of a improvment to justify the change, but the whole point of the 
change is to 1) get the default values in 1 spot within the applications, 2) 
let the kiosk guys get to it somehow.  

> > > - directly in the default config file.
> > > - additional description file.
> >
> > or
> > -the current system of those apps that want to have a doc file discribing
> > how their config works do.
>
> the advantage being? that you don't need to rewrite anything, just stack
> it on the already present stuff? how convincing ...

I wasn't trying to be convicing.  I was pointing out how people currently do 
it.

> > The defaults have to be in the application.  There is no way getting
> > around that.
>
> says who?

Says those on the list.  Go read from last week.

> > > i see no problem with requiring a config/descriptions file for an
> > > application to run.  one could hack something together to make
> > > things still work if the app is run directly from the build dir,
> > > though.
> >
> > Those config files don't exist and the program crashes because it
> > needs the default values!
>
> oh, how sad. show me one non-trivial application that works correctly
> without having its data available.

Opera 

> kde is about user-friendliness, not
> about random-file-erasing-jerk-friendliness.

They are different?

> also, i don't know your
> programs, but mine output an error message instead of exploding if a
> required file is not found.

OK, it would output a message and then exit, but to the user it would still be 
the same, the app doesn't launch because of a technical reason.

-Benjamin meyer