Resedit (Was: Proposal for KControl)

[David Pashley]

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

On Sunday 30 June 2002 8:17 am, Waldo Bastian wrote:
> 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

Can I just point out that this is AIUI exactly how gconf works, so it should 
be possible to wrap gconf.  I haven't looked very hard at gconf, but I seem 
to remember that each application would provide an XML file describing each 
option like the data type and a text description that can be used by a config 
editor. It may be worth looking at.

- -- 
David Pashley
david at davidpashley.com
Nihil curo de ista tua stulta superstitione.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD4DBQE9HutHYsCKa6wDNXYRAgFlAKCHlwKhFTHx16V6QvEiOPC+GT4WZACTBNXc
WhOLaSuSrJ0bdhqaUoCgyg==
=BOxp
-----END PGP SIGNATURE-----