MCS design proposal

[Stephan Arts]

On 7/8/07, Brian J. Tarricone <bjt23 at cornell.edu> wrote:
> 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.

It is in Xfce < 4.6, but perhaps it would be a good idea to centralize
the Kiosk settings inside a *new* MCS.

This would make sure that individual applications do not need to worry
about it, and Kiosk-mode will work with *all* settings stored via MCS.
Theoretically, it would be possible to determine if a user is allowed
to change his workspace-margins between certain boundaries. I know
this is far fetched, but it is just to illustrate the general idea.

Personally, I like the idea of Kiosk-mode placed inside the mcs-manager.

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

Cheers,
Stephan