Resedit (Was: Proposal for KControl)

[Waldo Bastian]

On Saturday 29 June 2002 11:48 pm, Holger Freyther wrote:
> Am Sunday 30 June 2002 01:33 schrieb Cristian Tibirna:
> > On Saturday, 29 June 2002 16:51, ian reinhart geiser wrote:
> > > In the end what I am getting at is, can we limit what is done via the
> > > UI and make a ResEdit type of app that allows you to tweak things that
> > > only geeks really care about?
> >
> > A start at this was done many times. The oldest I remeber is Antonio
> > Larrosa's, of 4-5 years ago (!!!)
> >
> > The problem with the resedit approach is that we don't have the
> > infrastructure for it. It would become necessary, for a resedit to
> > function, that all KDE-compliant apps save _all possible_ configuration
> > options in an XML file in a stadardised file repository. I mention this,
> > because Antonio's initial work was based on parsing all config files
> > available in
> > $KDE_HOME/share/config (and perhaps, if much increased complexity is
> > acceptable, hierarchically parse all rc files in all $KDEDIRS config
> > locations) and then, for each option read, have a factory generate a
> > standard widget: a text lineedit for text entries, a radiobutton for a
> > bool entry, a numedit, a color picker for a color entry etc. etc.
> >
> > Again, problem with this aproach was that it is nowhere stated in the
> > styleguides that an app has to save all possible configuration options at
> > first run. And what happens with apps not yet ran at least once?
>
> Didn't we change the behaviour for kiosk mode that only changed options are
> written to the file into $KDEHOME?

Yes, we did.

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)

Oh, and we need someone who is actually going to make all this :-)

Cheers,
Waldo
-- 
bastian at kde.org  |   SuSE Labs KDE Developer  |  bastian at suse.com