MCS design proposal

[Brian J. Tarricone]

On Sun, 8 Jul 2007 13:07:20 -0400 Erik Harrison wrote:

> I don't really speak current MCS, so maybe I'm being stupid. But
> unless we specify ways to alter the daemon's behavior, then why do we
> need an IPC interface to the same ol' config files?

The current MCS daemon behavior sucks.  It's the only process allowed
to *set* config values, and no other clients connecting to it are
allowed to do so.

> The advantage of
> MCS to me is being able to plugin something like a kiosk mode,

No, the current MCS daemon has nothing to do with kiosk mode.  Kiosk
mode is implemented (poorly, in many cases) in each individual
application.  It's totally settings-manager-unaware.

> or have
> the daemon figure out where I want to store my data if I'm running an
> application remotely.

Yeah, this is one of the nice things about current MCS, but really, all
it's doing is abusing XSETTINGS for this, and I don't think it's
totally necessary to have network transparency for settings as well.

> I really think that all of the stuff about opening a settings dialog
> should go away. The MCS application as anything special should go
> away. An app can open it's own dialog, and if you install a .desktop
> file, then so can anything else. I'd like to see the
> xfce-settings-show style app that simply aggregated .desktop files in
> the Settings category. Then the Settings menu in the desktop menu can
> go away, as it's a violation of all things holy.

Yeah, I agree.  This also lowers the barrier to writing another
implementation of the spec.  The part that knows about parsing
special .desktop files to deal with settings panels can (in Xfce's
case) run in the same process as the settings daemon proper, or not.
Let's leave the UI out of the settings manager proper.  (Though we'd
need a separate, likely Xfce-specific spec for how to handle the
settings panels.)

	-brian