Proposal for a general setup panel (overview)
huysmans at users.sourceforge.net
Wed Aug 21 10:33:25 CEST 2002
At 09:52 AM 8/21/02 +0200, you wrote:
> > 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
Some people would consider this 'hijacking' of the standard and it assumes
we always run with our own xsettings manager. This more or less makes it
impossible to use parts of xfce in other environments (e.g. xfwm4 for GNOME
or ROX) while still being able to change settings. I'm not saying this is
wrong, but it's a consequence of using XSETTINGS, isn't it?
Would it be possible to use our own XFSETTINGS window and use the protocol
described in XSETTINGS for our own settings? The xfsettings manager can then
manage both settings windows or only the xfce one if there is another
settings manager present.
I don't know if this is smart or even possible, but I thought I'd suggest it
> > 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
Yes indeed. There's lots of small thing all programs have to do. It will be
very useful to have a common library with support functions.
- running programs
- reporting (errors, warnings, info)
- opening files, (images with preview ?)
Some of this code could be taken from xfce4.
- extended window manager hints. Setting and reading the desktop hints.
Perhaps this should be separate. It would be useful for pagers, taskbars,
the panel, the desk menu, ...
> > 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 ?
A big difference of course is that with ROX the configuration is all
in-process, so that makes some things a bit easier.
However if we decide on a communications protocol (XSETTINGS) and have a
library to communicate with the settings manager the difference may not be
If I remember correctly ROX options system uses two types of configuration
- one xml file to describe the dialog. This file includes the type of widgets
to use (like glade) and the names of the options. There may be information
on the limits of each option and a default value as well, I'm not sure.
- separate parts of ROX read their own config file and register options with
the options system. The option is registered by name, which must match the
name in the dialog config file. It can also provide callback functions that
will be called when something changes.
If we want to use something like this we have to use separate xml files to
describe the dialog for each application.
Now I go back to work ;-)
>Olivier <fourdan at xfce.org> http://www.xfce.org
>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 http://www.xfce.org
>Xfce4-dev mailing list
>Xfce4-dev at moongroup.com
More information about the Xfce4-dev