Gdk motion event changed behavior in 2.18

View: New views
3 Messages — Rating Filter:   Alert me  

Gdk motion event changed behavior in 2.18

by Nicola Fontana-3 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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.

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.18

by Alexander Larsson :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On 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.18

by Nicola Fontana-3 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Il 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