Proposal for a general setup panel (overview)

[Biju Chacko]

On 17 Aug 2002 23:32:09 +0200, Olivier Fourdan wrote:

> - We standardize on xsettings protocol for all settings (note this
> doesn't include apps data such as xfce4 menus for example)
> - We need to write our own xsetting manager
> - A tree view will give access to all option, ordered by applications.
> - It will be modular. Every application that wants to use it will have
> to provide a plugin for the xsetting manager. That plugin will be in
> charge of loading/saving specific settings and display part of the
> GUI.- to call the GUI, from the application, the application will set
> a specific atom (X11) to an hidden window belonging to the xsetting
> manager and then send a synthetic MapRequest event to that window
> (using XSendEvent). The role of the atom is to provide the specific
> module to display. E.g., xfce4 wants to display its setup panel, more
> specifically the option for the panel position, it will first set the
> atom XFCE_SETTING_MODULE to "apps/xfce4/position" and send an XEvent
> to a given window.
> - If the path to the module to display, the xsetting-manager will
> display a message stating that the module is not installed or not
> implemented.
> 
> What do you think ? 

I'll be honest here and say that much of it went over my (admittedly
low) head.

If i understood correctly:

1. XSettings is the mechanism by which option changes are communicated
to individual applications.

2. The applications use the X stuff which I didn't understand to notify
the xsetting manager to display the appropriate plugin which knows how
manipulate it's settings.

This mostly sounds OK to me. I just have a couple of comments on the
plugin mechanism. IMHO, the biggest disadvantage of plugins would be
that it would encourage a profusion of config file formats and styles.
I'm a great believer in consistency for it's own sake. 

In addition it's a lot of code -- all of which will have bugs and which
will need maintenance. That's not good, when you realize that they will
all be doing similar things.

I suggest a slightly different method. I would suggest that each
application define some meta-data about it's config options. It would
contain information like option name, data type and validation rule.

Options generally come in two types: numeric and string. They would
either fall within a range, be one or more of a set of values or conform
to a regex. 

Given that much information, it should be possible to render the
appropriate widget: a spin button for a numeric range, a drop down list
for a set of values or a text box for a regex. Similarly the validations
could be generalized too. Basically the config dialog could be rendered
according to the appropriate meta-config.

I think the biggest advantage to this would be to prevent redundancy
between plugins. Who wants to reinvent the wheel? There would also be
only a single codebase to maintain.

Am I making any sense? Usually I can't tell. ;-)

-- botsie

-- 
-----------------------------------------------------------------------
Biju 'botsie' Chacko                        biju_chacko at vsnl dot net
http://www.symonds.net/~botsie
-----------------------------------------------------------------------