GNOME Bugzilla – Bug 690791
gtkwindow only sends startup notification once
Last modified: 2016-01-27 17:20:16 UTC
gtkwindow.c contains this: static gboolean sent_startup_notification = FALSE; then this: else if (!sent_startup_notification) { sent_startup_notification = TRUE; gdk_notify_startup_complete (); } which is more than a little bit broken when used with GtkApplication. Currently it's possible to work around this by querying the startup notification ID out of gdk and explicitly setting it on the window but that's asking a bit much of application developers. Probably we should just always calls gdk_notify_startup_complete(). Then we should modify GDK to unset the startup notification ID once complete() is called and ignore calls to complete() if the ID is unset. This will properly allow windows presented after a new ID is set to be associated with that ID.
I'm missing some background here. Why is it broken ? What problem does it cause ? Are we redefining what startup notification means ?
It's a pretty complicated story. Here's the highlights: On first startup everything is OK because: - sent_startup_notification is FALSE, so gdk_notify_startup_complete() gets called - the GTK leader window has the startup notification ID property set on it and mutter finds it there. On future activations (ie: forwarded startup notification ID via D-Bus) things are not good: - we set the timestamp properly because that gets queried out of GDK - we don't set the startup notification ID on the window at all because I misunderstood how this all worked (I thought it was done automatically because I didn't understand that it was done via the leader window) - the startup notification completion is only signalled via a hack in GtkApplication after_emit default handler The upshot: - I want to remove the hack and have startup notification working properly after any gdk_x11_display_set_startup_notification_id() call (not just for the first window shown). - Although we currently send a "startup complete" message (via the aforementioned hack) and therefore avoid the spinning busy cursor, we do not in any way advertise the link between the newly created window and the provided ID. The most visible problem caused by this is that for the second activation, if you request a window to be opened on a particular desktop, this request will be ignored and it will open on the current desktop. -
*** Bug 723639 has been marked as a duplicate of this bug. ***
The analysis here is wrong: 1) Setting the startup ID on the leader window is perfectly fine (or will be when mutter bug 723636 lands) 2) The problem is not that there is no link from the window to the startup sequence - the link exists, through the leader window. The problem is that GApplication is calling notify_startup_complete() too early, so mutter sees the _NET_STARTUP_INFO ClientMessage before the MapRequest, clears the startup sequence and drops the workspace information on the floor. Other WMs probably have the same problems. Metacity in particular has the same bug.
Yeah. It seems startup-notification with GtkApplication is just 100% broken right now. It sends the ClientMessage to remove the sequence before mapping the window.
Fixed by https://git.gnome.org/browse/gtk+/commit/?id=04e727709d562d7a86a115723d0356592ab06333
Actually, leaving this open so Ryan can do future cleanups. But this at least fixes the bugs mentioned.
Created attachment 319844 [details] [review] Tweak startup-notification after the first window Presently, Gtk will only send a startup notification completion message for the first window that is shown. This is not good for the case of GtkApplication, where we are expected to participate in startup-notification for all windows. We have avoided this problem by manually emitting the startup complete message from after_emit in GtkApplication. Unfortunately, this causes problems for windows that are shown with a delay. It is also a dirty hack. The reason for the original behaviour is simple: there is a static boolean in gtkwindow.c which controls it. We remove this. Instead, clear the startup notification ID stored in GDK when sending the completion message. GtkApplication will re-set this the next time an event comes in which needs startup-notification handling. In the non-GtkApplication case, newly shown windows will still not send the message, since the cookie will have been cleared. Finally, we remove the hack from GtkApplication's after_emit. This will probably cause some regressions in terms of lingering startup notification messages. The correct solution here is to always use gtk_window_present(), including when merely opening a new document (with a new tab, for example).
Review of attachment 319844 [details] [review]: Looks good to me.
Attachment 319844 [details] pushed as 0d10986 - Tweak startup-notification after the first window