RFC: KConfig XT (KDE 3.2)

[Oswald Buddenhagen]

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

to be of any use for kconfedit, the config meta info needs to be
installed. obtaining the description by executing the "authoritative
application" in "dump mode" is out of question for both practical
reasons and because it simply feels wrong (it's sort of built-in reverse
engineering). so the alternatives are:
- directly in the default config file. this solution is potentially
  slower for the simple case because of reading lots of unneeded info,
  but things could be optimized a bit by supplying flags to the kconfig
  constructor telling it which meta-info should be actually stored in
  the in-memory maps.
- additional description file. the advantage is, that the admin does not
  need to create a second config directory if he wants to create/change the
  global defaults but still have the kde defaults at hand. disadvantage
  is, that this would be even slower than the "inlined" meta info if
  kconfig is supposed to do operation validation at runtime (whether the
  right read/write*Entry variant was called on a key, whether a key
  exists at all, etc.).

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.

the use of a kautoconfig-alike is orthogonal to the choosen method, so i
won't bother thinking about it (i'm not so much the gui programmer :).

the use of generated config containers (kprefs) is orthogonal to it as
well.
the advantage of a config container is it's absolute type and reference
safety; violations are detected already at compile time.
however, at the same time this can be a problem, too, particularily if
the layout of the configuration is floating (entries defined by other
entries). this only means, that this can't be made the only option.

greetings

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