ossi at kde.org
Fri Aug 1 11:41:30 BST 2003
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.
Hi! I'm a .signature virus! Copy me into your ~/.signature, please!
Chaos, panic, and disorder - my work here is done.
More information about the kde-core-devel