These days exposure happens only on the native windows (generally the
toplevel window) and is propagated down recursively. The expose event
is only useful for backwards compat, and in fact, for double buffered
widgets we totally ignore the event (and non-double buffering breaks
on wayland).
So, by not setting the mask we avoid emitting these events and then
later ignoring them.
We still keep it on eventbox, fixed and layout as these are used
in weird ways that want backwards compat.
Without properly cleaning up GtkMenu private attach state
(GtkMenuAttachData) when the attached widget is freed, we would end up
with an invalid pointer to a freed widget. Trying to detach from that
widget would cause a segmentation fault.
https://bugzilla.gnome.org/show_bug.cgi?id=752761
GtkInspector is opening a separate display connection, which makes
it more likely that gtk_get_current_event() returns an event from
the "wrong" display.
Remove checks for NULL before g_free() and g_clear_object().
Merge check for NULL, freeing of pointer and its setting
to NULL by g_clear_pointer().
https://bugzilla.gnome.org/show_bug.cgi?id=733157
This was causing menus to show up in the wrong position in case the menu
popped up towards the top and/or left.
The change to the requisition was in error; it is the allocated size
of the menu, not the toplevel, and doesn't include the shadow.
https://bugzilla.gnome.org/show_bug.cgi?id=591258
Since you can't take grabs on unmapped windows, GtkMenu takes a grab on
the menu in a convoluted way: it first grabs another window, shows the
menu window, and then transfers the grab over to the GtkMenu widget.
For normal menubars, this is perfectly fine, as the first window it grabs
is our toplevel, and that gets picked up in our transient path. For
GtkMenuButton or other spurious uses of gtk_menu_popup, it creates a new
temporary input-only window which it takes the grab on, known as the "grab
transfer window". Since this window isn't a transient-for of our new menu
widget window, the grab isn't noticed when we go to show it, and thus the
menu ends up as a new toplevel.
Add a special hack to GtkMenu and the Wayland backend which lets us notice
this "grab transfer window", and include it in our grab finding path.
It's sort of terrible to have to hack up the widgets instead of just the
backend, but the alternative would be an entirely new window type which is
managed correctly by GDK. I don't want to write that.
GtkMenu calls gtk_widget_size_allocate on its GtkWindow during
gtk_menu_popup_for_device if the menu has not been realised. This can cause the
allocation of the GtkWindow and the size of the GdkWindow to become out of sync
because a top level GtkWindow does not attempt to re-size the GdkWindow when
its allocation is set.
https://bugzilla.gnome.org/show_bug.cgi?id=695120
This replaces the previously hardcoded calls to gdk_window_set_user_data,
and also lets us track which windows are a part of a widget. Old code
should continue working as is, but new features that require the
windows may not work perfectly.
We need this for the transparent widget support to work, as we need
to specially mark the windows of child widgets.
https://bugzilla.gnome.org/show_bug.cgi?id=687842
