After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 568588 - Nautilus registers with the session before it's ready.
Nautilus registers with the session before it's ready.
Status: RESOLVED OBSOLETE
Product: nautilus
Classification: Core
Component: general
unspecified
Other Linux
: Normal normal
: ---
Assigned To: Nautilus Maintainers
Nautilus Maintainers
Depends on:
Blocks: 568385
 
 
Reported: 2009-01-21 19:32 UTC by Ray Strode [halfline]
Modified: 2012-09-07 19:44 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Ray Strode [halfline] 2009-01-21 19:32:54 UTC
Right now Nautilus is started in the "Desktop" phase of startup by gnome-session.  That phase is started after the "Initialization" phase where gnome-settings-daemon is started.  gnome-session waits for that phase and other phases to complete before eventually emitting the SessionRunning signal over the session message bus.

In bug 568385, I wrote a patch to try to get rid of a hard coded 8 second timeout for fallback background setting in gnome-settings-daemon.  The patch didn't work because nautilus says "I'm ready" to gnome-session before it sets its background, and SessionRunning gets emitted before nautilus has even shown it's icons.

Nautilus should delay registering with the session manager until it's loaded its background, icons, etc.
Comment 1 Ray Strode [halfline] 2009-01-21 20:20:30 UTC
Looking through the code it seems like eggsmclient registers as soon as it parses the command line arguments.

We should probably either add a new api to eggsmclient to initiate the registration later, or just have nautilus use the "register by daemonizing" escape hatch and drop eggsmclient usage.

Dan, what do you think?
Comment 2 Dan Winship 2009-01-21 20:24:02 UTC
(In reply to comment #0)
> Nautilus should delay registering with the session manager until it's loaded
> its background, icons, etc.

Ugh, no, it really shouldn't. Loading icons and backgrounds and stuff takes time, and there's no reason to make the entire session wait for that. (IOW, if you do this now, someone else is just going to undo it later while trying to speed up startup, so we might as well do it right the first time.)

After thinking about this for not-very-much-time-at-all, I think nautilus and g-s-d should probably negotiate control over the desktop using an X manager selection, which would then let g-s-d reacquire control later if nautilus exits, etc. (And nautilus just grabbing the selection before registering with the SM wouldn't take much time at all, so it wouldn't slow down session startup.) But like I said, I didn't spend much time thinking about this, so there might be obvious problems with that plan.
Comment 3 Dan Winship 2009-01-21 20:25:08 UTC
(In reply to comment #1)
> Looking through the code it seems like eggsmclient registers as soon as it
> parses the command line arguments.
> 
> We should probably either add a new api to eggsmclient to initiate the
> registration later, or just have nautilus use the "register by daemonizing"
> escape hatch and drop eggsmclient usage.
> 
> Dan, what do you think?

Yes, this is a bug in EggSMClient. See bug 563635 comment 8.
Comment 4 Ray Strode [halfline] 2009-01-21 20:34:45 UTC
Actually g-s-d already looks for the NAUTILUS_DESKTOP_WINDOW_ID property on the root window.

So really we just need that set before nautilus registers.
Comment 5 Cosimo Cecchi 2010-12-18 18:26:27 UTC
Ray, is this still an issue with a 2.91.x nautilus? I changed some things in the interaction with EggSMClient in the meanwhile.
More specifically, we now start the application with the SMClient in disabled state, using a slightly tweaked version of [1], and enable it later.

[1] http://git.gnome.org/browse/libegg/commit/?id=dc8db697dfaf8e57fbc9fe5251675a27e8c54f44
Comment 6 Ray Strode [halfline] 2011-01-04 17:46:03 UTC
Hmm, looking through the history you removed smclient support entirely since asking comment 5, so I'm not sure my answer would be as relevant anymore.

If we're not going to autostart nautilus anymore that's fine.  But what about fallback mode?  If nautilus is autostarted we have to tell the session manager somehow that it's registered (either using eggsmclient, or fork() early and _exit parent when child is ready) or it will timeout waiting on nautilus, I think.

That registration step has to happen after 

nautilus_application_create_desktop_windows ()

to make sure SessionOver isn't emitted prematurely.

Note, also, that since comment 2 was posted, alex added the selection danw mentioned to nautilus.  We could have g-s-d and nautilus negotiate using that as well (although I think it would still be good to synchronize at startup to prevent selection handoff from happening during login which could potentially screw up the cross fade if its in progress)
Comment 7 Dan Winship 2011-01-05 15:29:11 UTC
(In reply to comment #6)
> If we're not going to autostart nautilus anymore that's fine.  But what about
> fallback mode?  If nautilus is autostarted we have to tell the session manager
> somehow that it's registered (either using eggsmclient, or fork() early and
> _exit parent when child is ready

or the org.gnome.SessionManager API

> ) or it will timeout waiting on nautilus, I
> think.

only if it still has an X-GNOME-Autostart-Phase in its .desktop file. If that's removed too, then when people do autostart it, it will be started with all the other ordinary applications, and gnome-session won't care whether or not it registers.
Comment 8 Cosimo Cecchi 2011-01-12 11:16:03 UTC
Ray: nautilus is being removed from the 3.0 sessions, see  https://bugzilla.gnome.org/show_bug.cgi?id=633288, so my guess is we should remove the X-GNOME-Autostart keys from nautilus' desktop file too. If I understand correctly, it wouldn't be necessary to register with gnome-session anymore at that point.
Comment 9 Ray Strode [halfline] 2011-01-12 14:26:22 UTC
well we may still have a small race for the fallback case then.  The signal will get emitted as soon as all applications are started.  If nautilus is one of the last ones started then SessionRunning could get emitted before nautilus_application_create_desktop_windows ().

To fix this, we'd need to synchronize g-s-d and nautilus in some more explicit way.  We could use the selection mentioned in comment 2 and comment 6, but we still may end up with an interrupted cross fade.

We could come up with a more elaborate scheme were nautilus requests the selection instead of steals it, and wouldn't be given it until after any pending cross fades are finished.  That's getting a little complicated though.

Given the race is pretty small and this is only an issue for the fallback mode, I'd say we should probably leave things as is.  If the problem seems more pervasive then i think it's going to be then we should consider just disabling the cross fade for fallback mode.
Comment 10 Cosimo Cecchi 2011-02-25 20:46:06 UTC
It seems nautilus is not autostarted even when in fallback mode, so this would be entirely obsolete.
Comment 11 Bastien Nocera 2011-03-11 19:30:21 UTC
Removed the timeout in master.
Comment 12 Bastien Nocera 2011-03-11 19:33:56 UTC
It's still a problem if the user chooses to show desktop icons, but certainly not a high priority one.

Reopening as I closed the wrong bug.
Comment 13 Cosimo Cecchi 2012-09-07 19:44:56 UTC
I think this can be closed as obsolete now; Nautilus is not autostarted and I don't think we do cross-fading.