Tk Source Code

If multiple displays are used, and a toplevel with a menu is located on a different display than the root window, then posting the menu will not cause the menu to visibly appear. The menu is posted, though: it can be interacted with programmatically and with the mouse or keyboard.

Note that I observe this using essentially two graphics cards (one is connected via built-in DisplayPort, the other is connected to a DisplayLink USB adapter), so I don't know this is the case for multiple displays connected to the same graphics card.

Revised fix is now applied to core-8-6-branch.

Yes, please do.

Thanks, Marc. Would it be okay then to apply it to 8.6 as well?

I am OK with it.

PS Thanks for the other recent patches.  I will get to them before too long.

I now notice that Tk 9 contains the approach from ca2ebe1fca-fix.diff (i.e. use the undocumented appearance: argument). It was included in the initial changes for CGImage drawing ([a7e2553a07]), and so was likely accepted unintentionally. Are the Tk Aqua maintainers okay with keeping this approach?

I notice that this issue only seems to be present when the System Preferences setting “Displays have separate spaces” is enabled. (Reasons for having this enabled is that it allows using multiple displays when an app is fullscreen; the only reason I’m aware of to have it disabled is that it does not allow a single non-fullscreen window to span multiple displays—I wonder if this is the underlying cause, which could indicate an bug in AppKit menu APIs.)

The behavior is different when this setting is disabled, but I’m not sure I can accurately and exhaustively describe how. With the existing approach in core-8-6-branch, menus can be posted programmatically on a different display than the toplevel, but for some reason posting a menu in response to a mousebutton click seems to always post the menu to the same display as the toplevel even when the coordinates are hardcoded.

Whether multiple graphics cards are used may not matter because of this setting.

I misunderstood jal_frezie’s comment. That issue is apparently due to a limitation when using popUpMenuPositioningItem:atLocation:inView: with a specific NSView. The approach suggested in my comment dated 2019-08-10 02:52:55 does not have this limitation. I would like to see if Tk Aqua developers are okay with using the undocumented appearance: argument so as to avoid a regression where menus have light/dark appearance based on what is set in System Preferences rather than what may be set for a specific toplevel. I will see if I can come up with a patch for testing…

Note that a menu will still not visibly appear (as of version 8.6.12) if posted on a different display than its own toplevel window.

This patch does address the problem, and appears to have no side effects. Thanks for the patch; committing to trunk and core-8-6-branch.

I have attached a new patch 07cfc9f0-fix.patch which I believe fixes the problem. There might be better choices for some of the variable names I used.

The approach used in the patch looks for the parent window of the menu that is a "real" (i.e. non-menu) toplevel with an associated NSView; this NSView is then what is used, rather than always using the one associated with the root toplevel window. This approach appears to fix both issues of menus not appearing on a different display than the root window, and menus only using the appearance of the root window even when a different appearance is set for the menu's parent real toplevel window. I am not aware of any potential regressions this approach might introduce.

The patch can be tested using the attached demo, menutest.tcl. The demo creates menus for both the root window and a child toplevel, and sets the appearance of the root window to aqua (light appearance) while setting the child toplevel's appearance to darkaqua. Clicking inside of the root window should display a menu with a light appearance; and clicking inside of child toplevel should display a menu with a dark appearance, even after dragging the root window or child toplevel to a different display than the other.

As I don't use a dual monitor setup, I am unable to test this, but the menu should continue to pick up the system display mode (dark or light) - if this patch causes the menu to always display as light, then that is a regression.

However, I haven't figured out how to get the appearance for a menu, nor have I figured out how to get the toplevel for one, since it doesn't seem to be recorded in menuPtr->tkwin->privatePtr->toplevel

I have probably misunderstood the purpose of this toplevel field, and more importantly neglected that a menu is a toplevel window, at least on other platforms—I don't know to what extent this is still true for Aqua.

Someone more knowledgable about AppKit and the existing code might know how to get the correct view, if that's indeed the cause; I suspect this might be easy to fix for someone who already knows where to look.

If a proper solution for this issue can't be found yet, though, then I think it would be better to incorporate the workaround I found in time for 8.6.10. That way, menus for anyone working on multiple monitors are at least usable, even though they won't support dark appearance (which is new in 8.6.10, or at least unknown to anyone who hasn't tried trunk or core-8-6-branch). I am attaching a brief patch for the workaround.

I updated the description to be more precise.

I'm inclined to think that the cause of this issue is that, in TkpPostMenu() (tkMacOSXMenu.c), the view of the root window is always used in the call to popUpMenuPositioningItem:atLocation:inView:; it should instead use the view for the toplevel containing the menu.

Some observations:

• Menus always use the appearance of the root window rather than their toplevels. If the appearance of a toplevel is overridden with ::tk::unsupported::MacWindowStyle appearance, that toplevel's menus are unaffected; but if the root window's appearance changes, then so will that of any menus, regardless of which toplevel they belong to.

• Replacing

      [menu popUpMenuPositioningItem:item
  			atLocation:[win tkConvertPointFromScreen:location]
  			    inView:view];

  with

      [menu popUpMenuPositioningItem:item
  			atLocation:location
  			    inView:nil];

  does allow menus of a non-root toplevel to appear on a different monitor than the root window. With this approach, menus will always use a light appearance, unless an undocumented appearance: argument is also specified. However, I haven't figured out how to get the appearance for a menu, nor have I figured out how to get the toplevel for one, since it doesn't seem to be recorded in menuPtr->tkwin->privatePtr->toplevel. Even doing

  menu .m;
::tk::unsupported::MacWindowStyle appearance .m

  will crash with:

  Failed to read appearance name.
Abort trap: 6

  .