Resedit (Was: Proposal for KControl)

Cornelius Schumacher schumacher at
Sun Jun 30 09:19:28 BST 2002

On Sunday 30 June 2002 09:17, Waldo Bastian wrote:
> Like Cristian says, you need some sort of XML file (well, it can be
> anything but XML would be a good candidate) that covers all possible
> config options, explains what it can be used for and that has some
> formal description of the values it can have. You can't extract this
> information from the config files themselves.
> What makes it difficult is that you don't want to parse scuh a XML
> file when you don't strictly need it (when running the app itself)
> but at the same time you want to assure to some degree that the
> config-entries actually used by the application are in agreement with
> the ones defined in this XML file.
> A way to achieve that is to have an optional "validation mode" in
> which an application verifies that it doesn't access config-entries
> that aren't described in the XML file. That validation mode could
> then be activated during development and be disabled for a release.
> This validation could also be used to ensure that everywhere where an
> entry is read, the same default value is used.
> Such a validator could probably also be used to generate or update a
> skeleton for the XML file, e.g. it can check which entries the
> application tries to read and add entries in the XML file for that.
> That way the developer only has to add the documentation and tweak
> things a bit. (I.e. to properly support variable named groups or
> keys)

Couldn't we do it the other way around and generate the code that reads 
and writes the config entries from the XML file? Then we have only one 
place where the config options are specified and automatically get a 
nice C++ class for the configuration which is convenient to use in an 
application. We could even try to automatically generate code for the 
configuration dialogs, at least for some standard types. This could 
significantly improve consitency across different apps.

Cornelius Schumacher <schumacher at>

More information about the kde-core-devel mailing list