After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 697380 - Event translation not done when clicked widgets has own window
Event translation not done when clicked widgets has own window
Status: RESOLVED OBSOLETE
Product: gtk+
Classification: Platform
Component: Backend: X11
unspecified
Other Linux
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2013-04-05 17:32 UTC by Bastien Nocera
Modified: 2018-04-15 00:37 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
test.c (2.33 KB, text/plain)
2013-04-05 17:32 UTC, Bastien Nocera
Details

Description Bastien Nocera 2013-04-05 17:32:00 UTC
Created attachment 240777 [details]
test.c

Click on the label at the bottom of the window in the test case.

With a GtkToolbar:
** Message: button press on layout (pick all)
** Message: button press on stage (pick reactive)

With a GtkLabel:
** Message: button press on layout (pick all)
** Message: button press on stage (pick reactive)

My guess is that since it doesn't paint a background, picking fails, but the widget still appears correctly when using CLUTTER_PICK=dump-pick-buffers.

Toggle the BROKEN define to the working case.
Comment 1 Bastien Nocera 2013-04-11 00:10:12 UTC
The empty toolbar (without the label) still triggers the problem, and I've been able to reproduce this problem on Intel and ATI drivers which should rule out a driver bug.

And "With a GtkLabel" case should have read:
** Message: button press on Onscreen Texture (pick all)
** Message: button press on controls (pick reactive)

I'm guessing that GtkClutterActor not implementing ->pick could be a problem here.
Comment 2 Emmanuele Bassi (:ebassi) 2013-04-11 11:02:33 UTC
(In reply to comment #1)

> I'm guessing that GtkClutterActor not implementing ->pick could be a problem
> here.

no: ClutterActor has a default pick implementation, which will paint the actor and its children.
Comment 3 Bastien Nocera 2013-04-11 11:47:34 UTC
The event's coordinates should be the hint here:
** Message: button press on stage (pick reactive) at 165.000015,21.000015

The value of the "y" coordinate should be closer to 200 (the default size of the window), but it seems that the event's coordinates (which are relative to the toolbar, as it has its own GdkWindow) aren't getting translated to the parent XWindow (the stage)'s coordinates.

Adding some debug to gtk-clutter-offscreen.c it looks like offscreen_window_to_parent() transforms the coordinates correctly, but *after* the mouse button press.

Clutter-Gtk-Message: offscreen_window_to_parent from 170.000000,27.000000 to 170.000000,198.999985
Comment 4 Bastien Nocera 2013-04-11 12:32:53 UTC
The button press is handled first:

Thread 1 (Thread 0x7ffff4187a00 (LWP 14163))

  • #0 button_press_cb
    at test.c line 8
  • #1 _gtk_marshal_BOOLEAN__BOXEDv
    at gtkmarshalers.c line 130
  • #2 _g_closure_invoke_va
    at gclosure.c line 840
  • #3 g_signal_emit_valist
    at gsignal.c line 3234
  • #4 g_signal_emit
    at gsignal.c line 3384
  • #5 gtk_widget_event_internal
    at gtkwidget.c line 6722
  • #6 gtk_widget_event
    at gtkwidget.c line 6379
  • #7 propagate_event_up
    at gtkmain.c line 2393
  • #8 propagate_event
    at gtkmain.c line 2501
  • #9 gtk_propagate_event
    at gtkmain.c line 2536
  • #10 gtk_main_do_event
    at gtkmain.c line 1658
  • #11 _gdk_event_emit
    at gdkevents.c line 69
  • #12 gdk_event_source_dispatch
    at gdkeventsource.c line 364
  • #13 g_main_dispatch
    at gmain.c line 3054
  • #14 g_main_context_dispatch
    at gmain.c line 3630
  • #15 g_main_context_iterate
    at gmain.c line 3701
  • #16 g_main_loop_run
    at gmain.c line 3895
  • #17 clutter_main
    at ./clutter-main.c line 980
  • #18 main
    at test.c line 76

Thread 1 (Thread 0x7ffff4187a00 (LWP 14163))

  • #0 offscreen_window_to_parent
    at ./gtk-clutter-offscreen.c line 73
  • #1 _gdk_marshal_VOID__DOUBLE_DOUBLE_POINTER_POINTER
    at gdkmarshalers.c line 248
  • #2 g_closure_invoke
    at gclosure.c line 777
  • #3 signal_emit_unlocked_R
    at gsignal.c line 3584
  • #4 g_signal_emit_valist
    at gsignal.c line 3328
  • #5 g_signal_emit
    at gsignal.c line 3384
  • #6 to_embedder
    at gdkwindow.c line 2329
  • #7 gdk_window_coords_to_parent
    at gdkwindow.c line 7270
  • #8 gtk_widget_translate_coordinates
    at gtkwidget.c line 5513
  • #9 gtk_window_button_press_event
    at gtkwindow.c line 6961
  • #10 _gtk_marshal_BOOLEAN__BOXEDv
    at gtkmarshalers.c line 130
  • #11 g_type_class_meta_marshalv
    at gclosure.c line 997
  • #12 _g_closure_invoke_va
    at gclosure.c line 840
  • #13 g_signal_emit_valist
    at gsignal.c line 3234
  • #14 g_signal_emit
    at gsignal.c line 3384
  • #15 gtk_widget_event_internal
    at gtkwidget.c line 6722
  • #16 gtk_widget_event
    at gtkwidget.c line 6379
  • #17 propagate_event_up
    at gtkmain.c line 2393
  • #18 propagate_event
    at gtkmain.c line 2501
  • #19 gtk_propagate_event
    at gtkmain.c line 2536
  • #20 gtk_main_do_event
    at gtkmain.c line 1658
  • #21 _gdk_event_emit
    at gdkevents.c line 69
  • #22 gdk_event_source_dispatch
    at gdkeventsource.c line 364
  • #23 g_main_dispatch
    at gmain.c line 3054
  • #24 g_main_context_dispatch
    at gmain.c line 3630
  • #25 g_main_context_iterate
    at gmain.c line 3701
  • #26 g_main_loop_run
    at gmain.c line 3895
  • #27 clutter_main
    at ./clutter-main.c line 980
  • #28 main
    at test.c line 76

Comment 5 Bastien Nocera 2013-04-11 14:37:21 UTC
Doing the same dance as GtkWindow does:
  gdk_window_get_user_data (event->window, (gpointer *)&src);
  if (src && src != widget) {
    gtk_widget_translate_coordinates (src, widget, event->x, event->y, &x, &y);
  } else {
          x = event->x;
          y = event->y;
  }

solves the problem. But that should really be handled within GtkClutterEmbed, so it sends out the correct values for x/y relative to itself rather than one of its children.
Comment 6 Alexander Larsson 2013-04-11 15:04:03 UTC
This is how events always work in Gtk+. The GdkEvent coordinates are *always* relative to GdkEvent->window, so events that bubble up don't get the coordinates rewritten, this is independent of any offscreen windows or not.
Comment 7 Bastien Nocera 2013-04-11 17:53:21 UTC
So this is my problem. Still, I cannot find a clear mention of the problem in the API docs (a mention for each "x" or "y" member in the GdkEvent* structs would be nice), and the code to use is impossible to guess, and most likely unusable from g-i.
Comment 8 Matthias Clasen 2018-02-10 05:26:31 UTC
We're moving to gitlab! As part of this move, we are moving bugs to NEEDINFO if they haven't seen activity in more than a year. If this issue is still important to you and still relevant with GTK+ 3.22 or master, please reopen it and we will migrate it to gitlab.
Comment 9 Matthias Clasen 2018-04-15 00:37:36 UTC
As announced a while ago, we are migrating to gitlab, and bugs that haven't seen activity in the last year or so will be not be migrated, but closed out in bugzilla.

If this bug is still relevant to you, you can open a new issue describing the symptoms and how to reproduce it with gtk 3.22.x or master in gitlab:

https://gitlab.gnome.org/GNOME/gtk/issues/new