[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