Re: Pluggable settings daemon

["William Jon McCann" <mccann jhu edu>]

Hi Jens,

Sorry for the long delay.

On Nov 18, 2007 10:58 AM, Jens Granseuer <jensgr gmx net> wrote:
> On 16.11.2007 13:48, Rodrigo Moya wrote:
>   On Thu, 2007-11-15 at 13:29 -0500, William Jon McCann wrote:
> > >  * The current settings daemon is only modular at the gobject level
> > > [1].  It is all or nothing.  And it isn't clear that we want to have
> > > all of these objects (eg. keybindings and typing break) loaded at the
> > > login window.
> > >  * At least to some people, the idea of GDM depending on
> > > gnome-control-center may be undesirable.
> [...]
>
> > it makes a lot of sense, and if we are going to share it, I guess we
> > could:
> >
> > - have the daemon in GDM
> > - have the modules you need in GDM
> > - have the other modules in gnome-control-center, and load them when the
> > session starts.
>
> That seems like an awkward setup, though, doesn't it?
>
> If the daemon and some of the modules were in gdm, we'd suddenly
> have a hard dependency on gdm in the desktop and it would become
> impossible (or at least very hard) to run a Gnome session with
> other login managers.

Agreed.  I don't think having g-c-c depend on gdm is going to work.

> A lot of the stuff the daemon does is directly coupled to the
> respective capplets, so I'm not sure separating g-s-d and the
> modules from g-c-c makes a lot of sense, either. The major
> result of such a move would be that in 90% of the cases we'd have
> to release two modules in unison (g-c-c and g-s-d).

Hmm, I'm not sure this is big deal.  We'll be one the same release
schedule either way.  I guess I'm basically proposing that we formally
split the configuration interface from the mechanism.  Particularly,
so that GDM doesn't have to depend on the configuration tools.  But
anyway, you make a fair point.

> On the other hand, if I understood Jon correctly, gdm's dependency
> on the settings modules is entirely optional. For some settings
> (e.g. the MouseTweaks stuff) you need the settings module if you
> want those features available in gdm, but if you don't need those
> features, you don't need the settings modules, either.

Right.  And it also allows the configuration GUIs to add more complex
dependencies without impacting GDM.

> Adding an optional dependency on g-c-c to gdm looks like the
> best arrangement for those reasons. That way we can keep all
> the settings-related stuff in g-c-c, but selected features could
> be used from gdm as well.

Well, it is less than ideal for the reasons I mentioned above.  But it
would be better than what we have now.

I'm going to go ahead and work on the issues that I described in my
response to Rodrigo.  We'd need these regardless of where the module
will live.

Thanks,
Jon