Re: nautilus vs. gnome-settings-daemon "race"

[Mark McLoughlin <mark skynet ie>]

Hi Jacob,

On 16 Jul 2002, jacob berkman wrote:

> On Tue, 2002-07-16 at 01:57, Mark McLoughlin wrote:
> > Hi Jacob,
> >
> > On 15 Jul 2002, jacob berkman wrote:
> >
> > > On Fri, 2002-07-12 at 14:54, jacob berkman wrote:
> > > > gnome-settings-daemon currently checks to see if nautilus is running,
> > > > and if so won't draw the background image.
> > > >
> > > > gnome-session starts gnome-settings-daemon before nautilus, so nautilus
> > > > isn't running when gnome-settings-daemon goes to draw the background.
> > > > this causes the background to get drawn twice, which slows down login a
> > > > bit.
> > >
> > > here's a different approach - since gsm spawns gsd, we can just tell it
> > > directly via monikers whether it should draw the background or not.
> >
> > 	That sounds better, a lot easier and cleaner to do with an
> > item handler.
> >
> > 	What I'm getting at is, if the bug in bonobo-activation is
> > fixed, we can remove all this again - right ?
>
> 1.  it's not a bug - it's a feature

	It's a feature that bonobo components do not connect to the
session manager - sure - its just poorly implemented.

> 2.  it would still be nice to be able to tell gsd that we are going to
> run nautilus so that it doesn't do the background stuff if nautilus is
> just going to do it in a few seconds.

	Well sure, but not this way - gnome-session should not be
special casing clients. I think the simplest solution should be that
g-s-d does not draw the background unless specifically enabled. I
*think* this is what /desktop/gnome/background/draw_background is
for ? If so, why not just have this off by default, and if some
decides to turn nautilus drawing the backround off, then they turn this
on ..


	And to go back to gsm starting and respawning g-s-d (sorry I
didn't discuss this when you were initially doing the work) - gsm
clearly shouldn't be doing this. g-s-d is clearly being session
managed, just explicitly. And why ? Because bonobo-activation prevents
components it activates from being session managed. Alernatives I see
are ...

	1) Allow bonobo components to connect to the session manager
if it wants. This could be controlled be an oaf_attribute in the
.server file.

	2) Not allow g-s-d to be activated by bonobo-activation -
simply by not installing the .server file. g-s-d would be part of
default.session again and would register itself with
bonobo-activation, purely so apps could bootstrap to it. So, you're
pretty screwed if it is removed from the session - but you're pretty
screwed if the panel, nautilus etc. is removed from the session too.
Its just a bit more obvious you're screwed.

	3) Decide that since g-s-d is a bonobo component, gsm has no
place respawning it and add a feature to bonobo-activation to respawn
componenets when they die. You would still need some way to start it
initially.

	I would like (1) to be possible, but I don't think (2) is too
bad a solution.

Good Luck,
Mark.