mirror of
https://gitlab.gnome.org/GNOME/gtk.git
synced 2024-11-18 17:10:04 +00:00
75ecdf50a3
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. |
||
|---|---|---|
| .. | ||
| protocol | ||
| gdkapplaunchcontext-wayland.c | ||
| gdkcursor-wayland.c | ||
| gdkdevice-wayland.c | ||
| gdkdisplay-wayland.c | ||
| gdkdisplay-wayland.h | ||
| gdkdnd-wayland.c | ||
| gdkeventsource.c | ||
| gdkkeys-wayland.c | ||
| gdkprivate-wayland.h | ||
| gdkscreen-wayland.c | ||
| gdkselection-wayland.c | ||
| gdkwayland.h | ||
| gdkwaylanddevice.h | ||
| gdkwaylanddisplay.h | ||
| gdkwaylandselection.h | ||
| gdkwaylandwindow.h | ||
| gdkwindow-wayland.c | ||
| Makefile.am | ||