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

[Gregory Merchan <merchan phys lsu edu>]

On Fri, Jul 12, 2002 at 01:54:25PM -0400, 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.
> 
> this patch makes gnome-session set a property on the root window if it
> is going to run nautilus, and gnome-settings-daemon checks this and
> nautilus' gconf key at startup.  if they're both on, it won't draw the
> background.
> 
> i plan on committing this monday/tuesday, but comments/flames/criticisms
> are welcome.
> 
>  - jacob

Flame on!  But first a question.

Which do you want: to fix the problem or to cover it up for a while so that
GNOME uses 3 or more times as much code as needed?

There is the more general problem of which program controls the lowest
viewable window on the screen; Nautilus vs. g-s-d is a special case.

There is also KDE's desktop:
  http://mail.gnome.org/archives/nautilus-list/2002-July/msg00169.html

There may be conflicts with the way a window manager implements workspaces.
There are also other pseudo-root programs such as ROX-Filer and probably
something XFCE uses.

Setting a property on the root window may be fine as a kluge - and it may not
be, I haven't gone through the sequence yet - but eventually the code will
have to be removed.  Will you remember this when the time comes?

Interned atoms remain until the server is reset. Are the atoms necessary for
this worth the time it takes to go through the table of atoms?

It may take longer to set the property than it does to run g-s-d and have it
check. Does your solution fix the problem or just push it back?

gnome-session might be able to modify the arguments passed to g-s-d depending
on whether it is going to run nautilus. g-s-d could take an argument which
prevents it from drawing. Can the session manager do this and how does this
compare to interning atoms then setting and getting properties?

It takes time to do any checks. If the redundancy can exist without affecting
anything other than login time, is it worthwhile to remove it? Might it be
better to leave the redunancy in case one of the checks returns incorrect
results? Are any checks for this special case worthwhile?


Cheers,
Greg Merchan