|
View:
New views
3 Messages
—
Rating Filter:
Alert me
|
|
|
Gdk motion event changed behavior in 2.18Hi all,
after upgrading GTK+ from 2.16.4 to 2.18.2, an application I was working on stopped to react to GDK_BUTTON2_MOTION_MASK events. I resolved by adding GDK_BUTTON_PRESS_MASK but this issue will likely affect other applications too. A simple test case attached. Ciao. -- Nicola /* gcc -o event `pkg-config --cflags --libs gtk+-2.0` event.c */ #include <gtk/gtk.h> static gboolean event_grabber(GtkWidget *widget, GdkEvent *event) { g_print("%d\n", event->type); return FALSE; } int main(gint argc, gchar **argv) { GtkWidget *window; GtkWidget *widget; gtk_init(&argc, &argv); window = gtk_window_new(GTK_WINDOW_TOPLEVEL); widget = gtk_drawing_area_new(); /* 2.16 works with GDK_BUTTON2_MOTION_MASK only */ gtk_widget_add_events(widget, GDK_BUTTON_PRESS_MASK| GDK_BUTTON2_MOTION_MASK); g_signal_connect(widget, "motion-notify-event", G_CALLBACK(event_grabber), NULL); gtk_container_add(GTK_CONTAINER(window), widget); gtk_widget_show_all(window); gtk_main(); return 0; } _______________________________________________ gtk-devel-list mailing list gtk-devel-list@... http://mail.gnome.org/mailman/listinfo/gtk-devel-list |
|
|
Re: Gdk motion event changed behavior in 2.18On Thu, 2009-10-15 at 13:29 +0200, Nicola Fontana wrote:
> Hi all, > > after upgrading GTK+ from 2.16.4 to 2.18.2, an application I was > working on stopped to react to GDK_BUTTON2_MOTION_MASK events. I > resolved by adding GDK_BUTTON_PRESS_MASK but this issue will likely > affect other applications too. A simple test case attached. This is actually kinda complex, related to implicit grabs. When you press the mouse button the xserver looks, starting in the innermost window with the pointer and looking for a window with the button press mask set. This window gets an automatic "implicit" pointer grab for the duration of the mouse-down, causing events to only get sent to that window. However, if no window with the button press mask is found then there is no implicit grabs and events continue being reported as before. Your example did not work for me without the added GDK_BUTTON_PRESS_MASK when using metacity as the window manager, I think because metacity is a reparenting wm and has button press event mask on the frame window, but it did work with twm (and probably other non-reparenting wms like compiz) which doesn't do this. The reason it works with twm is that no other window has a button press mask so there is no implicit grab, meaning events continue to go to the window with the pointer. As soon as there is a parent window in the hierarchy with the button press mask set it will stop working. This could happen before if e.g. the widget was put in some other widget that had the mask set. This is exactly what happens in 2.18. With the client side windows work we always request button events on the toplevel window, and thus that gets the implicit grab and the child window gets no motion events. I'm not sure how we can fix this in 2.18, or even if we should. I mean, by necessity we do request button press events from X on the toplevel (so we can emulate button presses on virtual child windows), so we *will* get an implicit grab and can't pretend its not there (as we get different X events now). However, for you I recommend putting in the GDK_BUTTON_PRESS_MASK even for 2.16, to make sure it works with all WMs. _______________________________________________ gtk-devel-list mailing list gtk-devel-list@... http://mail.gnome.org/mailman/listinfo/gtk-devel-list |
|
|
Re: Gdk motion event changed behavior in 2.18Il giorno Mon, 19 Oct 2009 21:24:45 +0200
Alexander Larsson <alexl@...> ha scritto: > Your example did not work for me without the added > GDK_BUTTON_PRESS_MASK when using metacity as the window manager, I > think because metacity is a reparenting wm and has button press event > mask on the frame window, but it did work with twm (and probably > other non-reparenting wms like compiz) which doesn't do this. > > The reason it works with twm is that no other window has a button > press mask so there is no implicit grab, meaning events continue to > go to the window with the pointer. As soon as there is a parent > window in the hierarchy with the button press mask set it will stop > working. This could happen before if e.g. the widget was put in some > other widget that had the mask set. Many thanks for the detailed answer. I always thought to press and motion as totally disjoint events but effectively the grab of the button press was "logic", or at least this has little to do with gtk. As you correctly guessed I'm not using metacity but openbox and this has hidden the problem up to gtk 2.18. > I'm not sure how we can fix this in 2.18, or even if we should. I > mean, by necessity we do request button press events from X on the > toplevel (so we can emulate button presses on virtual child windows), > so we *will* get an implicit grab and can't pretend its not there (as > we get different X events now). For what it's worth, this helped me to found a fragile (hence, broken) approach to events so, in this specific case, I don't see any reason to change. Ciao. -- Nicola _______________________________________________ gtk-devel-list mailing list gtk-devel-list@... http://mail.gnome.org/mailman/listinfo/gtk-devel-list |
| Free embeddable forum powered by Nabble | Forum Help |