bastian at kde.org
Fri Aug 1 13:32:42 BST 2003
-----BEGIN PGP SIGNED MESSAGE-----
On Friday 01 August 2003 12:41, Oswald Buddenhagen wrote:
> 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.
Well, yes, reading the original back, I must give you that. I consider it a
logical expansion of the original proposal though.
> 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. The only meta-info that is
retrieved in the normal case at run time is the default value, but we need
that anyway (and do so already) in order to properly support system-defaults
(as opposed to application-defaults)
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.
> - 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. I don't think run time type
safety is any safety at all for that matter.
As far as "several apps touching the same config files", that's where we tend
to have things like KGlobalSettings.
The original proposal for KConfig Xt didn't include type safety as goal.
> - 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.
Yes, the runtime interpreter for the meta information still needs to be added
to this picture.
> 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. *)
I think it's good that most issues are othogonal now because it gives us
I think there are two major requirements:
1) Tools that require runtime processing of meta-information (e.g.
config-editor) need to have access to an installed version of the
2) Users and admins would like to have access to a human readable description
of the meta information (description of the config file)
And as an implementation constraint, I would add:
3) We should preferably have only one formal config description
language/format to make it easier to become familiar with for
users/admins/developers and to be able to share implementation between
runtime and copile tools.
I think that gives use two viable options:
A) Use a formal config description language that extends the current
.ini-style configuration files.
*) These files can then double as a provider of system defaults if they are
installed under $KDEDIR/config.
*) Assuming that the formal description part is "readable enough", end-users
would have direct access to the formal config description as their human
readable description of the config file.
*) The files don't NEED to be installed under $KDEDIR/config, they could also
be installed under $KDEDIR/config.info for example.
B) Use an xml based config description language and use these to generate a
separate config description file for human consumption.
*) These xml files should then be installed somewhere, e.g. under
$KDEDIR/config.meta for example.
*) The config description files for human consumption should also be installed
somewhere, e.g. under $KDEDIR/config.doc
a*) The config description files for human consumption can be in .txt format
but also in a better looking format such as html.
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.
- - b*) might not be that useful if you consider that KConfig tends to strip out
comments when updating files.
- - People on this list have remarked that users wouldn't want to use a
text-editor for editing config files anyway but rather use the yet-to-come
kde-config-editor. I think there is truth to that but I also think we
shouldn't forget about sysadmins that prefer to use vi-over-ssh instead.
(Mental note: important that the kde-config-editor supports remote config
- - In scenario A) cfgc would need to be changed to use this config description
format instead of xml obviously.
- - I'm inclined to think that B) is the more elegant solution.
bastian at kde.org -=|[ SuSE, The Linux Desktop Experts ]|=- bastian at suse.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
-----END PGP SIGNATURE-----
More information about the kde-core-devel