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?

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

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

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.

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

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)

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

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.

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.

It seems nautilus is not autostarted even when in fallback mode, so this would be entirely obsolete.

Removed the timeout in master.

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.

I think this can be closed as obsolete now; Nautilus is not autostarted and I don't think we do cross-fading.