Re: Plans for 2.20

[Jens Granseuer <jensgr gmx net>]

On 07.03.2007 19:41, Rodrigo Moya wrote:
> > > > > 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.
> > 
> the reason of those xrdb calls being in 3 places is bad planning, and
> the result of adding code as it's needed, which has resulted in the mess
> that g-s-d is today. So, with good planning and structuration, it
> shouldn't matter what we use, provided we implement the things
> correctly.

My point being, if those modules are independent of each other, you can't
do much "planning and structuration" to avoid those kinds of things.

> > 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.
> > 
> yeah, that's a good point, although current g-s-d just limits itself to
> call one function after the other with nothing known about priorities :)

Having one function call after the other makes for an imlicit priority.
Some of the comments in the code even state such dependencies explicitly.

> > > 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?
> > 
> if it becomes that, of course it would make more sense as a separate
> module (gnome-daemon). Then, g-c-c would just include the shell and the
> capplets.

Yeah, well, that's not quite what I meant.

> > 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?
> >
> that's how it's done today, and it works for the screensaver very well,
> but for the whole of GNOME, it starts to exist lots of unrelated
> solutions for very similar things (see my list of daemons existing right
> now, or the way to enable/disable different things in GNOME).

Maybe my problem is that I don't see the use case.

Jens