KPrefs status

[Zack Rusin]

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
> meta-information
>
> 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 
easier.

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

Zack

-- 
For every complex problem there is an answer that is clear, simple, and 
wrong. 
-- H L Mencken