(In reply to comment #0)
> Some applications that use multiple windows can sometimes temporarily end up
> without any windows on the screen as they're transitioning. This doesn't play
> well with gnome shell as it is very eager to go back to the overview if a
> desktop loses all windows. Since it doesn't switch back out of overview once
> the new window shows up, this gives a very poor user experience.
> 
> I was hoping that using the startup notification protocol would be enough to
> inform gnome shell that a new window was incoming, but I did a quick test
> program and the shell doesn't seem to pay any attention to startup notification
> events.
> 
> I guess gnome uses some other custom messaging system rather than the standard
> one as the shell seems to notice launches from other processes (like nautilus)
> just fine?
> 
> So is there a way for applications to play nice with the shell in this regard?
> Or is it a limitation of the current implementation? :/

The current implementation just waits a bit after the last window has been closed before going to the overview. So the app has that timeframe to map a new window before the overview switch happens. (currently one second iirc).

Ehm... odd. This code makes the shell notice the launch:

	c = Gdk.Display.get_app_launch_context(Gdk.Display.get_default())
	app = Gio.AppInfo.get_default_for_type("application/pdf", False)
	app.launch([], c)

This code does not:

	c = Gdk.Display.get_app_launch_context(Gdk.Display.get_default())
	c.set_icon_name("evince")
	app = Gio.AppInfo.create_from_commandline("evince", "Document Viewer", Gio.AppInfoCreateFlags.SUPPORTS_STARTUP_NOTIFICATION)
	app.launch([], c)

And if I monitor the startup notification events, they are identical except for the timestamp. What kind of voodoo is going on here?

(In reply to comment #1)
> 
> The current implementation just waits a bit after the last window has been
> closed before going to the overview. So the app has that timeframe to map a new
> window before the overview switch happens. (currently one second iirc).

Seems to be much shorter than that unfortunately. I have to remove all useful work in between the windows to get the thing to work. :/

Turns out that the monitor program from libstartup-notify doesn't show all the fields. The key attribute that gnome shell wants is "application id". Unfortunately you cannot set that from GIO, so I had to construct a new test program in C. This make the shell trigger properly, but unfortunately it still zooms out when the last window disappears.

So this is now fully a request to change that behaviour. Whenever there is a pending startup notification for a workspace, then the shell should not zoom out to the overview except on explicit user action.

(or provide another mechanism that allows applications to indicate that a new window will be here shortly)

This also affects standard Gnome tools such as Brasero, so should probably be given some priority.

We no longer open the overview after closing the last window on a workspace, and only remove the empty workspace after having navigated away from it, so marking this as fixed.