[prev in list] [next in list] [prev in thread] [next in thread]
List: gtk-devel
Subject: Re: gtk 3 stuck menu bug on Mac
From: Matthias Clasen <matthias.clasen () gmail ! com>
Date: 2017-11-20 13:04:20
Message-ID: CAFwd_vD-WYoJ+bD+b9zwQMs6U5tb6WMX_QZL5x+Bn5EBq1TH8g () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Sat, Nov 18, 2017 at 3:34 PM, <philip.chimento@gmail.com> wrote:
> On Sat, Nov 18, 2017 at 6:45 AM Christian Schoenebeck <
> schoenebeck@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?
>>
>
> No-one's really maintaining the Quartz backend at the moment, so if you
> felt like investigating this it would be really appreciated. You could try
> a 'git bisect' to see what change in GTK3 might have caused the regression
> and that would probably make it easy to see what would need to be changed
> in the Quartz backend.
>
>
As Philip, a git bisect might be helpful. But keep in mind that OS X builds
of GTK+ tend to include quite a few non-upstream patches, so keep any eye
out for those.
[Attachment #5 (text/html)]
<div dir="ltr">On Sat, Nov 18, 2017 at 3:34 PM, <span dir="ltr"><<a \
href="mailto:philip.chimento@gmail.com" \
target="_blank">philip.chimento@gmail.com</a>></span> wrote:<br><div \
class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" \
style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div \
dir="ltr"><div class="gmail_quote"><div><div class="h5"><div dir="ltr">On Sat, Nov \
18, 2017 at 6:45 AM Christian Schoenebeck <<a \
href="mailto:schoenebeck@linuxsampler.org" \
target="_blank">schoenebeck@linuxsampler.org</a>> wrote:<br></div><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex">On Freitag, 17. November 2017 00:51:25 CET Christian \
Schoenebeck wrote:<br> > What I found out so far is that whenever this problem \
occurs, both of the<br> > following two checks in function \
gtk_menu_motion_notify() (gtkmenu.c) return<br> > false and the function is thus \
aborted at this point:<br> ><br>
> menu_item = gtk_get_event_widget ((GdkEvent*) event);<br>
> ...<br>
> if (!GTK_IS_MENU_ITEM (menu_item) ||<br>
> !GTK_IS_MENU (parent))<br>
> return false;<br>
<br>
Looking further at this issue, the problem is probably not a timing issue like<br>
I first considered in my previous email. Fact is that the wrong widget under<br>
the mouse pointer is resolved forever whenever this issue starts to occur:<br>
<br>
At this code location above, the gtk_menu_motion_notify() function expects<br>
menu_item to be a "GtkMenuItem" gobject class, however when this issue \
occurs,<br> menu_item is pointing at its parent "GtkMenu" gobject \
instead.<br> <br>
I would understand if this misbehavior just happens immediately after a new<br>
menu pops up. But whenever this stuck menu issue occurs, I can continue to<br>
move the mouse pointer over all the visible menu items for hours and the<br>
resolved toplevel widget under the mouse pointer (resolved by the Quartz<br>
implementation) is always the GtkMenu widget instead of the respective<br>
GtkMenuItem widget.<br>
<br>
Since this issue only seems to happen on Mac, and since it worked flawlessly on<br>
Mac before, and since I see the Quartz implementation hasn't really changed<br>
(significantly) in the last couple years, was there some kind of important<br>
change in gtk 3 that still would need to be applied to the Quartz \
driver?<br></blockquote><div><br></div></div></div><div>No-one's really \
maintaining the Quartz backend at the moment, so if you felt like investigating this \
it would be really appreciated. You could try a 'git bisect' to see what \
change in GTK3 might have caused the regression and that would probably make it easy \
to see what would need to be changed in the Quartz \
backend.</div><div><br></div></div></div></blockquote><div><br></div><div>As Philip, \
a git bisect might be helpful. But keep in mind that OS X builds of GTK+ tend to \
include quite a few non-upstream patches, so keep any eye out for those. \
<br></div></div></div></div>
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic