Proposal for a general setup panel (overview)
Jasper Huijsmans
huysmans at users.sourceforge.net
Sun Aug 18 11:35:44 CEST 2002
Hey Olivier,
Now this is good news to wake up to on sunday morning. Welcome back.
Now please be patient with me, because I have problems getting my mind
around all this X protocol stuff. My comments, therefore, may be
completely off the mark, but I'll try anyway ;-)
On 17 Aug 2002 23:32:09 +0200
Olivier Fourdan <fourdan at xfce.org> wrote:
> Hi all,
>
> Back to work after 3 weeks. I didn't work on xfwm4 lately, but I still
> used (some) of my brain.
>
> I came with a proposal. Here comes the highlights :
>
> - We standardize on xsettings protocol for all settings (note this
> doesn't include apps data such as xfce4 menus for example)
If I recall correctly, the xsettings protocol makes use of _one_
property to store all settings. Should we be using this same property or
use a separate one?
> - We need to write our own xsetting manager
ROX Session uses the sample implementation, which seems to work well
enough.
> - A tree view will give access to all option, ordered by applications.
Agreed. How do applications tell the tree to put in extra branches (at
least the main program branch)? So how does xfce tell the manager to add
an 'XFce Panel' branch?
> - 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.
This may be the answer to the above. Do you mean that each app provides
a
gmodule with a standard API, which includes let's say:
char *get_app_name();
void add_notebook_page(GtkTreeView *tv,
GtkTreeIter *parent,
GtkNotebook *notebook,
GtkButton *revert);
Then the app just monitors the xsettings properties and changes on the
fly. The revert button idea is that the settings app provides the revert
button for the modules to connect to. That would give a nice modern
feeling to it, don't you think? I want to do that for the panel item
dialog as well.
> - 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.
Then the settings app needs to know how to find the specified option, or
is that left to the module?
> - 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 really love to see such a system. I just always have difficulty
understanding the X properties and messages. I need to find some example
code for that to improve my X programming skills.
A common way to store the configuration would perhaps also be nice to
have. Something xml based. Perhaps even a way to build the config module
from an xml file. Like what the ROX options system does.
I'm now working on unifying the panel control interface (launcher icons
and panel modules). And I want to have an instant-apply dialog for the
panel controls as well.
Greetings,
Jasper
--
IRC channel: #xfce on irc.openprojects.net
More information about the Xfce4-dev
mailing list