Re: Plans for 2.20

[Rodrigo Moya <rodrigo gnome-db org>]

On Wed, 2007-03-07 at 19:08 +0100, Jens Granseuer wrote:
> 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.
> 
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.

In fact, for the xrdb problem, I was thinking on having a xrdb module
that merged the 3 places into one. And as we need more stuff, I'm sure
we can restructure things as needed

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

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

> (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...)
> 
forget if you want the D-Bus part, that is a separate issue, since it
might not be needed at all if no external apps make use of the
interface.

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

>  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.
> 
it's not additional, it already exists, and until we're proven wrong, we
need it. That's why we still have g-s-d, which has been a 'throw all the
code you want to start with GNOME here' wastebasket.
-- 
Rodrigo Moya <rodrigo gnome-db org>