On Sat, Nov 18, 2017 at 3:44 PM, Christian Schoenebeck <schoeneb...@linuxsampler.org> wrote: > On Freitag, 17. November 2017 00:51:25 CET Christian Schoenebeck wrote: >> What I found out so far is that whenever this problem occurs, both of the >> following two checks in function gtk_menu_motion_notify() (gtkmenu.c) return >> false and the function is thus aborted at this point: >> >> menu_item = gtk_get_event_widget ((GdkEvent*) event); >> ... >> if (!GTK_IS_MENU_ITEM (menu_item) || >> !GTK_IS_MENU (parent)) >> return false; > > Looking further at this issue, the problem is probably not a timing issue like > I first considered in my previous email. Fact is that the wrong widget under > the mouse pointer is resolved forever whenever this issue starts to occur: > > At this code location above, the gtk_menu_motion_notify() function expects > menu_item to be a "GtkMenuItem" gobject class, however when this issue occurs, > menu_item is pointing at its parent "GtkMenu" gobject instead. > > I would understand if this misbehavior just happens immediately after a new > menu pops up. But whenever this stuck menu issue occurs, I can continue to > move the mouse pointer over all the visible menu items for hours and the > resolved toplevel widget under the mouse pointer (resolved by the Quartz > implementation) is always the GtkMenu widget instead of the respective > GtkMenuItem widget. > > Since this issue only seems to happen on Mac, and since it worked flawlessly > on > Mac before, and since I see the Quartz implementation hasn't really changed > (significantly) in the last couple years, was there some kind of important > change in gtk 3 that still would need to be applied to the Quartz driver?
If I remember correctly I already saw that issue when I started using gtk+3 on macOS, around 3.16/18. _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
