RFC: KConfig XT (KDE 3.2)

[Benjamin Meyer]

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.

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

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

or
-the current system of those apps that want to have a doc file discribing how 
their config works do.  The defaults have to be in the application.  There is 
no way getting around that.  If they are also in some other registery editor 
file then it is duplicate work which is where we are currently today and is 
no better and slower.

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

-Benjamin Meyer