KPrefs status

[Oswald Buddenhagen]

On Fri, Aug 01, 2003 at 02:32:42PM +0200, Waldo Bastian wrote:
> > > 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.
> 
> Well, yes, reading the original back, I must give you that.

> I consider it a logical expansion of the original proposal though.
> 
yes, it was also mentioned in the original thread.

> > 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
> 
> I never intended to read meta descriptions at run time in the normal
> case. The non-normal case would be a config-editor.
>
true

> The biggest difference with the original proposal is whether to
> install the application-defaults as system-defaults or whether to
> hard-code them in the application. With KPrefs I'm inclined to go with
> the latter although it is still possible to do the former as well.
>
i agree. *)
it also makes those "but i want my app to run without installing it
first"-sissies shut up. ;-P

> > - 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
> 
> Those two are closely related and stem from the desire expressed by 
> application developers to have type safety.
>
obviously. well, actually, the whole idea of kprefs is the compile time
type safety.

> I don't think run time type safety is any safety at all for that
> matter. 
> 
uhmm, well, it's exactly the same as qt's connect warnings. and it's
true that they are often missed ...

> As far as "several apps touching the same config files", that's where
> we tend to have things like KGlobalSettings. 
> 
sort of obvious.
but there are still other cases ... the same konqueror config is used by
various kcms. maybe, the description file could define sections by which
cfgc can generate several partial stubs.

> The original proposal for KConfig Xt didn't include type safety as goal.
> 
yeah, you got me. that was an invention of mine. logical expansion, you
know. :)

> 2) Users and admins would like to have access to a human readable
> description of the meta information (description of the config file)
> 
i would go for auto-generated man pages and/or chapters that are added
to applications' docs.
hmm, maybe it would even be ok to not generate any docu readable by
standard tools ... kconfedit can be viewed as a doc browser, too.

> A) Use a formal config description language that extends the current 
> .ini-style configuration files. 
> 
> B) Use an xml based config description language and use these to generate a 
> separate config description file for human consumption.
> [...]
> b*) The config description files for human consumption can be in .ini format 
> with non-formal descriptions as comments which would allow users/admins to 
> use them as templates by copying them to their config directory.

> Ramdom thoughts:
> - - b*) might not be that useful if you consider that KConfig tends to strip out 
> comments when updating files.
> 
yeah, that's why i implied kconfig xt would handle the meta info as an
integral part of the file format, not as comments. but the system
defaults are never written by kconfig, so the meta info needn't to be
preserved, consequently. stupid me. :}

> - - I'm inclined to think that B) is the more elegant solution.
> 
i think so, too. *)

*) for the same reasons: no unnecessary cruft at run-time. it's faster,
it's cleaner.

who is going to write the "kconfig designer"? i'm not going to edit xml
files by hand ... :)
i guess, that would make a good addition to kconfedit.

greetings

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