MCS design proposal
bl at lue.dk
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
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.
> 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