Xfce MCS Design Proposal
========================================================================

  1. MCS daemon
  2. Settings dialog

 

1. MCS daemon
------------------------------------------------------------------------

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

    <!-- ---------------------------------------------------------------
      Get/set methods and notification 
    ---------------------------------------------------------------- -->

    <!-- Sets a property / setting -->
    <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>

    <!-- Loads a property / setting -->
    <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>

    <!-- Notifies listeners of a property change -->

    <signal name="Changed">
      <arg name="channel" type="s"/>
      <arg name="property" type="s"/>
      <arg name="value" type="v"/>
    </signal>

    <!-- ---------------------------------------------------------------
      Settings dialog related methods 
    ---------------------------------------------------------------- -->

    <!-- Shows the main settings dialog (like xfce-setting-show without
         parameters) -->
	
    <method name="Show" />

    <!-- Shows a certain settings dialog (like xfce-setting-show xfwm4
         does it) -->

    <method name="ShowPlugin">
      <arg name="name" type="s"/>
    </method>
  </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 proxy 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. 



2. MCS plugins
------------------------------------------------------------------------

The D-Bus interface includes methods to invoke settings dialogs. Plugins
install a .desktop file somewhere (either $XDG_DATA_DIRS/applications/
or $XDG_DATA_DIRS/xfce4/mcs-plugins). They should have a special
'Category' value and 'Exec' should point to a command like 'xfwm4 -s'
('s' for 'settings') or 'xfce4-panel-settings'. It's completely up to
the plugin authors how they do it.

The 'name' attribute passed to org.xfce.MCS.ShowPlugin could for example
be the desktop-file ID.