Re: Plans for 2.20

[Jens Granseuer <jensgr gmx net>]

Sorry, should have gone to the list as well...

On 07.03.2007 18:56, Jens Granseuer wrote:
On 07.03.2007 17:11, Rodrigo Moya wrote:
> On Wed, 2007-03-07 at 13:38 +0000, Bastien Nocera wrote:
> > On Wed, 2007-03-07 at 10:48 +0100, Rodrigo Moya wrote:
> > > On Tue, 2007-03-06 at 22:52 +0000, Bastien Nocera wrote:
> > > > On Tue, 2007-03-06 at 10:53 +0100, Rodrigo Moya wrote:
> > > > > - Settings daemon:
> > > > > 	- Consolidate all xrdb calls into one
> > > > > (http://bugzilla.gnome.org/show_bug.cgi?id=314774)
> > > > Unbreak the number of gdk_window_add_filter, there's just too many (and
> > > > turning a11y on makes it install a filter that breaks other users of
> > > > gdk_window_add_filter)
> > > > 
> > > I was thinking on structuring the different subsystems in g-s-d to be
> > > more pluggable. That would allow 3rd party apps to install modules to be
> > > started with g-s-d. That would help in cleaning up the code, quite messy
> > > in some places right now. What do you think?

Wouldn't implementing the separate domains in g-s-d as independent modules
make optimizations such as those mentioned above (both xrdb and
gdk_window_add_filter) impossible? That separation is the reason why those
multiple xrdb calls exist in the first place.

Like Sergey said, I'm also somewhat concerned about the performance implications
of such a move.

You would also need some kind of priority mechanism for modules. At least in
current g-s-d, there are certain constraints on what must be run before what
else.

> > I think it's already hard to control what each part of g-s-d does while
> > all the code is available to us. Using another daemon (similar to KDE's
> > daemon-pluggable daemon) would be a better idea.
> > 
> well, that's what I suggest g-s-d to become, see attached doc.

Is g-s-d is the right place to put such functionality?

(Disclaimer: I haven't ventured much into dbus land, yet, so I'm just
tossing some random thoughts around which might just turn out to be
ramblings best ignored...)

Or maybe, do we need such a daemon at all? Could this not be done directly
by those "modules" (e.g. screensaver) implementing a well-defined dbus
interface? The line of thinking here being, if dbus can do activation,
why not the other stuff as well? This could mean there have to be thin
"dbus wrappers" around services which do not implement the dbus interface
themselves, but I wouldn't expect an additional full-fledged daemon to
be required.

Jens