[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: KPrefs status
From:       Waldo Bastian <bastian () kde ! org>
Date:       2003-08-01 12:32:42
[Download RAW message or body]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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

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)

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

Cheers,
Waldo
- -- 
bastian@kde.org -=|[ SuSE, The Linux Desktop Experts ]|=- bastian@suse.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE/Kl3qN4pvrENfboIRAoAgAJ945BkJ4RsPiCwCjzfGy6eOd44w4wCfdUW9
/QLbEF8XruRnjBDkl6+0RPg=
=mqlg
-----END PGP SIGNATURE-----

[prev in list] [next in list] [prev in thread] [next in thread]