GNOME Bugzilla – Bug 723636
group: select for property notifications on the leader window
Last modified: 2015-06-28 20:27:52 UTC
If we don't select for PropertyChangeMask, we never notice changes in _NET_STARTUP_ID, so meta_window_get_startup_id() returns a stale value for the second window of a gtk app (because gtk only changes the startup id on the leader), meaning that meta_screen_apply_startup_properties() bails and the workspace and timestamp are wrong (most importantly the workspace, because the timestamp is also communicated to gtk through the ID and already set properly)
Created attachment 268106 [details] [review] group: select for property notifications on the leader window
Hey, any update on this?
What exactly does this fix?
The return value of meta_window_get_startup_id (), which is used to apply workspace and timestamp from startup notification, in all gtk+ apps
Can we get this in for 3.12.1?
Review of attachment 268106 [details] [review]: ::: src/core/group.c @@ +175,3 @@ + event_mask = ColormapChangeMask; + if (ancestor->override_redirect) + event_mask |= StructureNotifyMask; I'd rather see something like this above in meta_group_new: gulong event_mask = 0; if (XGetWindowAttributes (xdisplay, group_leader, &attr)) event_mask |= attr.your_event_mask; /* Make sure to listen for PropertyChange events, since * we need to detect changes in _NET_STARTUP_ID on the * group leader... */ event_mask |= PropertyChangeMask; ::: src/core/screen.c @@ +3320,2 @@ sequence = NULL; + if (startup_id != NULL) This seems completely unrelated to "group: select for property notifications on the leader window". If you aren't going to split it out, it needs explaining in the commit message.
Pushed a simpler patch: https://git.gnome.org/browse/mutter/commit/?id=aea71fbd0119d31a69787985beb77bfac8842e93 GTK+ is still incorrectly doing startup-notification though.