Proposal for a general setup panel (overview)

Olivier Fourdan fourdan at
Wed Aug 21 09:52:34 CEST 2002

Ho Botsie;

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

So you may want to have a look at

There is a sample implementation available too, it makes things easier
to understand.

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

Nope, it not sent a particular application. All apps that use xsettings
protocol get notified and use or not the given settings.

> 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.

Nope, well, kinda, the plugin is in charge of loading/saving settings to
file and display a gui. The rest should be handled by the xsettings
> 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.

So why not making a shared lib handling the common parts ? I really wish
we could provide more than just a desktop, but also a basic devel

> 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.

That's another approach, probably closer to the ROX-filer way, if I
remember well. Thomas, still with us on this list ?

Olivier               <fourdan at>  
XFce is a lightweight  desktop  environment  for  various *NIX systems.
Designed for productivity,  it loads  and  executes  applications fast,
while conserving  system resources. XFce is all free software, released
under GNU General Public License.    Available from

More information about the Xfce4-dev mailing list