MCS design proposal

Bo Lorentsen bl at
Sun Jul 8 23:41:57 CEST 2007

Jannis Pohlmann wrote:

> All you would have to do is monitor all three channels or just
> "/root" (and in the latter case do the filtering on your own) by
> connecting to the "property-changed" signal of the XfceMcsChannel
> objects.
Ok, so channel naming is tree like, how nice.

> Not yet, but except some kind of org.xfce.MCS#IsReadonly function I
> don't see the need for additions to the API and the D-Bus interface.
> Most of the kiosk mode would be implemented inside the MCS daemon (e.g.
> based on a kiosk mode flag in the MCS daemon config and readonly flags
> for all properties affected by the kiosk mode).
And the kiosk mode will be invoked using the same tree, or only in one 
channel at a time ?

What kind of interface would I use if I needed to create a list of all 
available channels and there values, from a GUI frontend (regedit/gconf) ?

> As long as we have not made a decision about whether to implement this
> design or not there's really no need for naming conventions. We could
> use anything from a Java-packages-like scheme 
Its not the naming method as much as the structure of the content 
(system, panel or application), but I guess you are right, this need to 

Hope to see the document you made evolve to a more mature documentation 
of the new MCS to make it more simple for future Xfce developers to 
start using this. Maybe it need to be put into a wiki ?

> Let's decide about the MCS future first, before starting to discuss
> less important details. 
Check :-)

> Use the source, Luke. There's no good MCS documentation that I know of.
Yes, this much i know.

We really need to be able to present an overview to new developers so 
they know what Xfce (not only MCS) can do for them and how to get 
started (nothing big, but explanations and pictures).


More information about the Xfce4-dev mailing list