GNOME Bugzilla – Bug 79248
No notification when window is maximized
Last modified: 2011-02-04 16:11:52 UTC
When using sawfish, no GDK_WINDOW_STATE event occurs when a window is maximized
Get the "xprop" output on a maximized sawfish window and see if _NET_WM_WINDOW_STATE includes _NET_WM_WINDOW_STATE_MAXIMIZED
When window is maximized xprop output has the line _NET_WM_STATE(ATOM) = _NET_WM_STATE_MAXIMIZED_VERT, _NET_WM_STATE_MAXIMIZED_HORZ
The problem here is simply that GtkWindow doesn't select for PropertyNotify on its toplevels. Therefore its pure luck if gdk catches any changes in _NET_WM_STATE. One-line fix attached.
Created attachment 8011 [details] [review] gtkwindow.c patch
This patch works for me. Can it be applied?
Are there assumptions in GDK about being able to track state changes? (That is, do we ever do things out of PropertyNotify in gdk_event_translate() other than send them on to GTK+?) If so, then we need to add the PropertyNotify mask to all toplevel windows at the GDK level. (And even if not, it strikes me as a little odd to have to add the PROPERTY_CHANGE mask to get events apparently unrelated to GDK_PROPERTY_CHANGE events, so perhaps we should add it at the GDK level anyways.)
I was wondering about that as well, but wanted to attach just a minimal fix. If you decide to add PROPERTY_CHANGE_MASK in gdk, does that mean that gdk uses them only internally, or will they unconditionally be passed up to gtk ?
Meanwhile, I learned that gdk already does filtering for expose events (http://bugzilla.gnome.org/show_bug.cgi?id=54506), thus we should probably do the same for property notify: always select them for gdk's own purposes, but not propagate them to gtk unless they're requested by the event mask.
Yeah, that's probably best; I think it's very dubious if a program breaks when it gets events it doesn't expect, but that doesn't mean that programs *don't* break when they get events they don't expect.
Here is a patch to do so. I noticed that the symmetry between gdk_window_get_events and gdk_window_set_events is broken. The get method reports the StructureNotifyMask and PropertyChangeMask which gdk adds for its own purposes, even though the events may not be delivered (since the relevant flags in private->event_mask are not set. It would probably be best to simple return private->event_mask in the getter.
Created attachment 8127 [details] [review] patch for handling it internally in gdk
Looks fine to commit. (I was thinking that we should only select for PropertyNotify on toplevel windows, but I can't think of any particular reason that selecting on child windows would hurt, and doing it for all windows makes gdk_window_reparent() simpler.)
Committed on both branches. I guess selecting for property notify on child windows doesn't make a difference since you will hardly ever see properties on non-toplevel windows. How do you think about the get_events/set_events symmetry break ?
the symmetry break doesn't bother me much. And I would worry just a bit that if we made get_events() return GTK+'s idea of the event mask that we might break some app that was using XSelectInput() directly. Maybe just best ignored?