GNOME Bugzilla – Bug 568385
background plugin should wait for SessionRunning instead of 8 seconds
Last modified: 2011-03-11 19:34:09 UTC
Right now gnome-settings-daemon will wait 8 seconds for nautilus to start if it thinks nautilus is supposed to start. After 8 seconds, it assumes something went wrong and then takes over background handling. If a program adds an autostart desktop file to start in an early phase during login but fails to register with the session upon getting started then gnome-session will add a 10 second delay waiting for the phase timeout to hit before switching phases. So you can end up with g-s-d getting started and registering some-random-app getting started and not registering 8 seconds of blocking g-s-d doing nautilus's job 2 more seconds of blocking nautilus starting up and doing it's job. Instead of waiting an arbitrary 8 seconds, the background plugin should probably listen for the SessionRunning dbus signal before deciding nautilus won't show up. It would be even better if gnome-session offered notification of each phase transition, so we could wait for GSM_SESSION_PHASE_DESKTOP to finish, but SessionRunning is probably good enough.
This bug is bad because it breaks the recently added crossfade effect at login time if there's a buggy session client getting autostarted (like gnome-volume-control-applet)
Created attachment 126936 [details] [review] Wait for SessionOver before continuing So I took a stab at this today. It didn't work as well as I had hoped. Nautilus tells gnome-session it's ready before it sets the background. So we still need the original timeout to get things working with buggy session clients stalling login.
I filed bug 568588 to deal with the nautilus race. It's blocking on new api getting added to eggsmclient though. attachment 126936 [details] [review] isn't a bad stop gap. And when nautilus gets fixed we can just drop the g_timeout_add bit and call queue_draw_background directly.
Looks good, please commit.
*** Bug 561911 has been marked as a duplicate of this bug. ***
sorry for incorrect dupe.
Hrm, I don't know if it's still the current behavior, but it might explain why I'm seeing my background drawn late in my session when nautilus is ignored on startup, I guess.
It looks like we still have the unconditional 8 second delay: /* If the session finishes then check if nautilus is * running and if not, set the background. * * We wait a few seconds after the session is up * because nautilus tells the session manager that its * ready before it sets the background. */ manager->priv->timeout_id = g_timeout_add_seconds (8, (GSourceFunc) queue_draw_background, manager); We can probably drop it if SessionOver is properly synchronized now.
There's some relevant discussion going on in bug 568588.
commit fcf06249ee2cde3e1a7d0fe5bc800edd3bc88818 Author: Bastien Nocera <hadess@hadess.net> Date: Fri Mar 11 19:28:37 2011 +0000 background: Remove 8 second timeout when drawing background SessionRunning should now be right, and if it isn't, then we only break on people that want nautilus to manage the background window which it doesn't do by default. https://bugzilla.gnome.org/show_bug.cgi?id=568588