MCS design proposal

[Jannis Pohlmann]

Am Sat, 7 Jul 2007 15:40:22 +0200
schrieb "Stephan Arts" <stephan at xfce.org>:

> On 3/20/07, Jannis Pohlmann <jannis at xfce.org> wrote:
> > Hey all,
> >
> > I have uploaded my thoughts about a new MCS design to
> >
> >   http://lunar-linux.org/~jannis/mcs-design-proposal.txt
> >
> > This topic has been on our list for quite some time but we never
> > made it to a design draft. So here are my ideas. Hopefully they
> > will be start of a productive discussion - I hereby encourage
> > anyone to participate in it.
> > I'll keep the .txt updated with relevant opinions. Here's the
> > initial document:
> >
> > Xfce MCS Design Proposal
> > ========================================================================
> >
> > The MCS daemon is a process running in the background. It manages
> > all settings inside a root path (like $XDG_CONFIG_DIRS/xfce4/). The
> > settings could be stored in many different ways, e.g.
> >
> >   * one big XML file (not recommended, unflexible)
> >
> >   * several XML files in subdirectories, e.g.
> >
> >       $XDG_CONFIG_DIRS/xfce4/core/panel.xml
> >       $XDG_CONFIG_DIRS/xfce4/core/desktop.xml
> >       $XDG_CONFIG_DIRS/xfce4/applications/application-browser.xml
> >       $XDG_CONFIG_DIRS/xfce4/extensions/thunar-media-tags.xml
> >
> >   * .desktop files in subdirectories, e.g.
> >
> >       $XDG_CONFIG_DIRS/xfce4/core/panel.desktop
> >       $XDG_CONFIG_DIRS/xfce4/core/desktop.desktop
> >       ...
> >
> > Personally, I prefer the second solution as XML files give us the
> > possiblity to create property hierarchies.
> >
> > In the MCS concept, applications and libraries are not able to read
> > or write settings on their own. They have to query the MCS daemon
> > for this. Using D-Bus, we could define the following interface:
> >
> >   <interface name="org.xfce.MCS">
> >     <method name="Set">
> >       <arg name="channel" type="s" direction="in"/>
> >       <arg name="property" type="s" direction="in"/>
> >       <arg name="value" type="v" direction="in"/>
> >     </method>
> >     <method name="Get">
> >       <arg name="channel" type="s" direction="in"/>
> >       <arg name="property" type="s" direction="in"/>
> >       <arg name="value" type="v" direction="out"/>
> >     </method>
> >     <signal name="Changed">
> >       <arg name="channel" type="s"/>
> >       <arg name="property" type="s"/>
> >       <arg name="value" type="v"/>
> >     </signal>
> >   </interface>
> >
> > In this interface, all clients can query the MCS for settings based
> > on a channel (or domain, e.g. "xfwm4") and a property name (e.g.
> > "focus/follows-mouse"). The value parameter is a GValue ('v' stands
> > for variant) which makes handling different value types (string,
> > int, float, boolean etc.) pretty easy.
> >
> > The MCS daemon should probably also listen to XSETTINGS events. I
> > have no experiences with XSETTINGS, so I'm not exactly sure how
> > this would work though.
> >
> > MCS clients may connect to the "Changed" signal of the org.xfce.MCS
> > interface in order to be informed of property changes. Properties
> > may change if a) some other client sets them or b) the properties
> > file changes.
> >
> > Due to b) the MCS daemon also has to monitor all files for changes,
> > e.g. using FAM/Gamin.
> 
> I was just wondering, what is the status of this discussion (and the
> spec)?

There is no real status. I still have a more recent design draft
lying around on Doppio:

  http://www.foo-projects.org/~jannis/xfce4-mcs-design.html

It is incomplete though, as plugin interface (would probably be based
on .desktop files) is missing. I haven't had the time to finish it
yet. Anyway, the general design idea is what I would prefer instead of 
getting involved in GConf.

  - Jannis

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.xfce.org/pipermail/xfce4-dev/attachments/20070707/e50f00b2/attachment.pgp>