On 15-03-20 10:07 AM, Roger Davis wrote:

Hi Jim & Konstantin,

I can now add another data point on this topic. My boss bought me a nice new iMac 27" Retina which arrived a couple days ago (yayy boss!!), so I decided to do my first ever X11-free quartz-only gtk3 MacPorts install (arrrrgh gtk3-on-quartz!!). I am now seeing your menu insensitivity bug, another bug as well, and all my hard-won tweaks to get gtk3 looking nice re: font and theme issues under XQuartz have gone down the toilet and I'm back at square one. On to the details ...

(1) I had a bit of installation difficulty with MacPorts. For my previous
XQuartz gtk3 installs I always just did

port install gtk3

but to do this quartz-only install I followed some other instructions and did

port install cairo +quartz -x11
port install pango +quartz -x11
port install gtk3 +quartz -x11

The last command failed because it dragged in the gtk2 port which wanted a
pango with X11, so I started over:

port install cairo +quartz
port install pango +quartz
port install gtk3 +quartz -x11

That worked.

(2) My gtk3 app runs basically OK (and is not starting X11), but now shows
the message

*** WARNING: Method userSpaceScaleFactor in class NSView is deprecated on
10.7 and later. It should not be used in new applications. Use
convertRectToBacking: instead.

every time I start it. Naturally, my own code knows userSpaceScaleFactor from nothing, so it must be getting called somewhere within gtk3/whatever. There are other reports of this on the web (some of which state that it has led to fatal errors!!) but I have not yet seen any detailed explanation. Obviously it still afflicts gtk 3.14.9 and friends on quartz-only.

(3) Now, the context menu issue ... I am basically seeing the same problem you are (although I have *never* seen it under my XQuartz installs), but have some additional observations to add.

First, my popup menus (both those which I directly display within my own code as well as those displayed indirectly by GtkComboBoxText widgets) initially display with a transparent 6-ish-pixel-wide border the first time they are shown, but on subsequent displays show no border at all (but still suffer from the insensitivity bug). Weird.

Second, I can avoid triggering the bug if I initiate the menu display with a quick click-and-release. If on the other hand I trigger the menu with a depress-only mouse event, I see the bug as you have described. On my own direct popups, the menu displays to the lower right of the mouse cursor position. If I depress-only and move the mouse directly to the lower right the items are sensitive until I move the mouse out of the menu, but if I first move the mouse to the upper left and then into the menu, the items are never sensitive.

Jim, I don't see how this could have anything to do with X11 because (1) the latter is not running on my quartz-only install where the bug appears, and (2) the bug *never* appears on my XQuartz platforms.

Hope this helps,


Jim Charlton wrote:

I certainly should have mentioned that my observations were made under
the MAC OS X 10.10 (Yosemite) operating system.  I too have not been
able to observe this problem under Linux (Ubuntu).  As Konstantin has
pointed out, it does not seem possible to add a margin to the popup
menuitem box in Linux to test if the problem would arise.  I will try to
determine if the problem arises in the XQuartz X11 libraries or in the
GTK3 libraries.  But the incorrect motion event data seems to point to
the X11 libraries on the MAC.
gtk-app-devel-list mailing list

I can confirm that I see exactly the same thing that you do. Holding down the right mouse button while moving the mouse gives the effect that you see. On checking which widget is under the cursor at each motion event... I find that not releasing the right button changes what is initially reported to be under the cursor (from GtkMenu to GtkMenuItem).

I used rather loose language when I referred to the XQuartz server. I am also actually using the Gtk3 + quartz and so am using the MAC quartz graphics library not the Xserver. A colleague here has suggested that it probably is not an incorrect event being sent from quartz as I imagined. It may be linked to either the handling of "enter" events, or perhaps the setting of event masks for the various widgets. I will continue to work my way through the code (gtkmenu.c) to see if I can figure it out.

jim...   Jim Charlton

gtk-app-devel-list mailing list

Reply via email to