GNOME Bugzilla – Bug 69934
Grab group problem with "global grabs"
Last modified: 2016-01-24 05:41:38 UTC
Chris Blizzard points out the following problem: If you create multiple grab groups, then gtk_grab_add() in one group doesn't affect event going to other grab groups. This is normally you want for modal dialogs, but is _not_ what you want if you are using gtk_grab_add() in >>>>>>> 1.2878 conjunction with a gdk_pointer_grab() with owner_events = TRUE. As a consequence of this, if you have multiple grab groups, menus won't pop down properly if click on windows in other grab groups, though they will if you click on different applications or other windows in the same grab group. Possible fixes: - Add API to allow distinguishing "global gtk_grab_add" from "grab group specific gtk_grab_add" - Do tricks so that when a grab is present with owner_events = TRUE, events delivered to other window groups in the same process are rewritten to look as they would be if they occured over windows in other processes. [ That is, they would have event->window switched to be the grab window, and coordinates converted to be relative to the grab window ]
I'm going to try and work around the menu issue using tricks as described in the second option. This won't give the "process modal" capability, but as long as the app maintains a list of process groups, it's pretty easy to write a "grab for the entire process function.
Except that when you are doing embedding, a component doesn't know about the app's grab windows. Fixing this with a new explicit global grab seems so much more elegant to me, even if it does mean an API addition. It won't break existing clients, or break them any more than they were broken to begin with.
gtk_grab_add() is currently used in situations where a group-local grab would be wanted (think modality for the popups of a modal filesel) and where a global grab would be used. So, no simple addition of a global grab function will fix existing code. I also don't think gtk_grab_add_global() / gtk_grab_remove_global() is very elegant as an API, and the interaction with gtk_grab_add()/remove() isn't clear to me when there are multiple layers of grabbing. Something like that may be right long term, but not in the 2.0.0 timescale. The issue of dialogs from embedded windows is going to be a difficult one to address.
Keep in mind I'm not talking about out of process components, only in process ones at this point. The out of process component issue is hard, as we discussed.
Fixed problem with gtk_grab_add() and gdk_pointer_grab() Fri Mar 1 18:39:44 2002 Owen Taylor <otaylor@redhat.com> * gdk/x11/{gdkevents-x11.c,gdkmain-x11.c,gdkprivate-x11.h, gdkwindow-x11.c}: Robustify tracking of pointer grab window. * gdk/x11/gdkmain-x11.c: Keep track of current keyboard grab window. * gdk/x11/gdkmain-x11.c (gdk_pointer_grab_info_libgtk_only, gdk_keyboard_grab_info_libgtk_only): Private libgtk => libgtk API for finding out current grab information. * gtk/gtkmain.c (rewrite_event_for_grabs): Rewrite events so that the effective behavior of owner_events = TRUE is changed to "deliver events to same window group normally" instead of "deliver events to same application normally. #69934 Problem of "real global grabs" being left to later API additions.
time to close this