zack at kde.org
Fri Aug 1 20:39:55 BST 2003
On Friday 01 August 2003 08:32, Waldo Bastian wrote:
> > 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 design flexibility.
> 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.
These are definitely very closely related, by having #1 and the config
editor you pretty much automatically get #2 and #3 makes #1 somewhat
> 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
> Ramdom thoughts:
> - 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 files)
Man, a while ago, right after 3.0, I moved my .kde to a different
machine and found myself grepping through configs to change a few
settings. I got irritated and wrote kconfedit, which was really
supposed to be only for my personal use. I put it in kdenonbeta and as
many applications - it became good enough for my personal use but never
got to the point where it could be the actual KDE config editor. A week
ago George reminded me off it and now this discussion made me start
working on it. KConfEdit needs a lot of work but it can certainly
become that tool we're looking for. I need to abstract the parsing,
which is pretty internal and rather nasty (as the code in many
applications we write for ourselves :) ) and I'll add support to edit
config files remotely and change the gui a bit. Also the undo
functionality is missing. Besides I don't see a problem.
> - 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.
Personally I like b a little more also.
For every complex problem there is an answer that is clear, simple, and
-- H L Mencken
More information about the kde-core-devel