Re: gtk 3 stuck menu bug on Mac



On Montag, 20. November 2017 08:04:20 CET you wrote:
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.

Actually I have no idea where I would find those "OS X build patches".

Anyway, I decided to be pragmatic and I am now using the attached patch to 
address this Quartz driver bug on Mac. The actual root cause seems to be that 
the Quartz driver does not generate crossing events correctly under all 
situations (i.e when menus or tooltips appear or disappear), which in turn 
causes the pointer info to reflect often an old, wrong top level window, 
sometimes even NULL, which finally leads to the described symptoms with hanging 
menus. Because when the current toplevel window info is already wrong, then it 
is impossible for Gtk to resolve the correct child widget that should receive 
pointer events.

So the patch does not fix the Quartz driver, instead it forces to update the 
pointer info very frequently instead (asking the native driver callback always 
about the latest top level window). It is a suboptimal approach to handle this 
issue, I know, but to be honest; in practice the user won't feel a performance 
penalty, and thus I decided for myself that it does not make sense for me to 
invest more days (or even weeks?) to restructure the Quartz driver's event 
generation code in a way expected by Gtk3 now, just to fix this bug in a more 
"clean" way from a pure theoretical point of view.

The rest is up to you to decide whether or whether not you might want to apply 
this or a similar workaround patch to upstream Gtk. All I can say from my side 
is that without addressing this issue at all, Gtk3 IMHO is not usable on Mac, 
because you end up with frozen menus in a matter of few seconds.

CU
Christian

Attachment: gtk3-quartz-menu-bug.patch
Description: Text Data



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]