RFC: KConfig XT (KDE 3.2)

[Oswald Buddenhagen]

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).

> > 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.

> > - 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 ...

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

> > 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. kde is about user-friendliness, not
about random-file-erasing-jerk-friendliness. also, i don't know your
programs, but mine output an error message instead of exploding if a
required file is not found.

greetings

-- 
Hi! I'm a .signature virus! Copy me into your ~/.signature, please!
--
Chaos, panic, and disorder - my work here is done.