KPrefs status

[Oswald Buddenhagen]

On Fri, Aug 01, 2003 at 11:49:39AM +0200, Waldo Bastian wrote:
> > fwiw, it might be worth checking, which things (particularily type
> > checking, enum conversions, etc.) considered for kconfig would be
> > duplicated in kprefs - i'd prefer not to have any, so it would be strictly
> > speaking better to implement (or at least design exactly) kconfig xt first.
> 
> This basically *IS* kconfig xt, this *IS* the new kconfig stuff. 
> 
no, it isn't. while it serves mostly the same purpose, it is very much
different from what you suggested originally.

the other concept was based on run time meta info retrival and
processing, while this approach is based on compile time processing.
this has several consequences:
- it's faster, as no meta description needs to be read at run time
- it's bigger, as the application contains stubs for every key. it will
  even duplicate code between the app and the kcm, as both need to link
  the stub. it becomes even better, if several apps touch the same
  config files, but only small parts of it. should every one of them
  link the whole stub?
- type safety is reached at compile time, not at run time
- it is built on top of kconfig, not into it. mostly due to the
  fact, that no meta info is stored inside the config files. *)
- editing the config files by hand does not become any simpler, as they
  stay like they are now. for the config editor it does not make any
  difference, except that it needs to have an own meta info interpreter
  instead of using kconfig's.

the question, whether defaults are hard coded into the binary (the stub)
or put into the default config file is basically orthogonal to this.
but given, that the default config wouldn't contain anything but those
defaults and would need to be generated from the xml file anyway, it
seems reasonable to put them into the stub to avoid having mostly
superflous files installed. *)

*) but then, the format of the description file is orthogonal to the
used concept ...

for those who do kinky things with kconfig, like storing dynamic
structures, neither of the two concepts is relevant.

greetings

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