|
|
| Product | |
| Support | |
| Everything Else | |
| BZ814: Windows Menu Placement in OS X | |
| Category |
Specification Change |
| The Problem |
When the Windows menu item is placed in a hierarchical menu, that menu does not display the currently open windows. (When placed in the main menu bar, the Windows menu is properly populated. |
| Discussion |
Classic Helix creates the Windows menu internally, so it works no matter where the Windows menu placeholder is placed. In Classic Helix, this includes hierarchical menus. However, the OS X Human Interface Guidelines (HIG) specify where the Windows menu is to be placed. Specifically, it is to be the last menu item in the main menu bar just before the Help menu item. (It is permissible to insert menus between the Windows and Help menus, but that is a special case that is outside the scope of this discussion.) OS X Helix respects the Mac OS X HIG, placing the Windows menu in the standard position regardless of where it is placed in the Helix user editor. In fact, the Windows menu is still placed according to the HIG even if the user's menu definition contains no Windows menu placeholder. The result is that the Windows menu placeholder is no longer supported in hierarchical menus. In this case, the menu item is displayed as usual, but the hierarchical contents are empty. |
| Additional Notes |
Using the OS X-supplied Windows menu gives us a bonus in that it contains commands for Minimize, Zoom, Bring All to Front, as well as enabling Command-` to cycle the frontmost window. These are available to all Helix users with no need to visit Design Mode to add them. However, because OS X commandeers Command-M for the Minimize function, Helix menus items that have been assigned Command-M will only work when no windows are open. There are three potential workarounds for this:
|