RFC: KConfig XT (KDE 3.2)

[Ralf Nolden]

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

On Saturday 15 March 2003 16:38, Waldo Bastian wrote:
> Your feedback is appreciated. See also kdecore/DESIGN.kconfig
>
> Cheers,
> Waldo
>

Hi Waldo,

> Plan A
> ======
>
> Instead of relying on the defaults that are hard-coded in the application,
> rely on default configuration files being installed in $KDEDIR. The
> technical changes required for this are very minimal, it is mostly a change
> in policy.
>
That's the plan that I already proposed last year. Nothing really happened to 
that because the requirement was that 

a) the default values are still hardcoded in the application so the programmer 
only needs to have one place to keep track of them
b) add the ability during the make install process to dump *all* values into 
the config file that gets installed.

This way you're making absolutely sure that even if the config file is missing 
the application runs without coredumping or misbehaving due to a missing 
config file. This is an absolute requirement.

The second is that you need to make sure that even when you change or add a 
setting that this will end up in the default config file without the 
programmer making the mistake of only changing the value in the code but not 
the default config file. Therefore the best is to call the application with a 
- --dump-config or --dump-defaults during make install or in the make process 
to actually write the defaults file.

Maybe that helps bringing up the ideas from last year again.

Ralf

> Type information can be provide by preceding every entry with a formalized
> comment.
>
> Work to be done:
> * KConfig needs to be extended to provide access to the default values
> provided by the default config files. KConfig already stores this
> information internally.
> * A formal comment structure needs to be designed that can convey
> type-information. Preferably in such a way that it is easily parsable by
> both machine and user.
> * KConfig needs to be extended, or another class created, that is able to
> parse the formalized comments.
> * A tool needs to be developed that can assist developers with the
> generation and verification of default configuration files that include
> type-information.
>
> Drawbacks:
> * We rely on default configuration files being properly installed.
>
> Plan B
> ======
>
> There is no plan B.

- -- 
We're not a company, we just produce better code at less costs.
- --------------------------------------------------------------------
Ralf Nolden
nolden at kde.org

The K Desktop Environment       The KDevelop Project
http://www.kde.org              http://www.kdevelop.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+dJoxu0nKi+w1Ky8RAvBoAKCREyopVT02fB/d9umDK879XmCqxQCeNk18
WtKzCkrl8sNXIbqL+UqWoII=
=/S1y
-----END PGP SIGNATURE-----