JDK-8099012 : New Menu API should support concept of a single appwide menubar, and work properly on Mac
  • Type: Enhancement
  • Component: javafx
  • Sub-Component: controls
  • Affected Version: fx1.3
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2009-09-28
  • Updated: 2015-06-16
  • Resolved: 2012-01-18
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
fx2.1Fixed
Related Reports
Blocks :  
JDK-8090449 - Mac: SQE needs API to determine current menu state on Mac
Blocks :  
JDK-8101261 - SQE: Implement test plan and specification for - New Menu API should support concept of a single appwide menubar
Blocks :  
JDK-8100569 - Add menu/menubar/menuitem related methods to Toolkit interface & implement them in QuantumToolkit for App wide menubar
Relates :  
JDK-8127259 - MenuBar.useSystemMenuBar needs to be dynamically switchable on/off
Relates :  
JDK-8127068 - GlassSystemMenu class in Quantum does not support visibility property for menus and menu items
Relates :  
JDK-8090985 - System-wide menubar improvements
Relates :  
JDK-8090562 - Keeping menu in the Mac menu bar when there is no more stage
Relates :  
JDK-8127858 - Mac: MacMenuItemDelegate does not set graphic correctly.
Sub Tasks
JDK-8100005 :  
Create new higher level API for menus to be used by controls and Toolkit - Closed
Description
We are designing a new api for the menubar.  I'd like to request two features of this API:

1)  the api should include the concept of a single menu bar. Some operating systems have a single menubar for the whole app. Other OSes have a menubar per stage. Today the single menubar is only on Mac, but this concept will be more widespread as we move into netbooks and mobile OSes. Historically the Swing menubar api has not supported this concept, resulting in lots of buggy hacks to implement a single menubar on Mac.  If the API supported this concept initially then we wouldn't need hacks.

2) the implementation of this new menubar API should work properly on Mac.  For the old Swing toolkit this should be pretty easy because Apple's implementation of JMenuBar can already do the event forwarding from a native Mac menubar. We just need to write our wrapper properly.  However, the Prism toolkit probably won't use the Swing painting thread, and ideally won't load AWT or Swing at all. This means we will lose the work done by the Apple Java team. We will have to implement the hooks to the native menus on our own. To make this clean we need the API to support it (see feature #1).
Comments
Changeset: http://hg.openjdk.java.net/openjfx/2.1/master/rt/rev/7572020a30ad
18-01-2012
A new boolean property "useSystemMenuBar" is added, with the default value set to false. The property acts as a request for the MenuBar skin to send the list of Menu instances to the system menu bar, provided that all of the following criteria are met: - The property useSystemMenuBar is set to true, either by calling setUseSystemMenuBar(true) on a MenuBar or by setting the property in CSS, e.g. ".menu-bar { -fx-use-system-menu-bar: true; }". - The platform supports a system menu bar. Currently this is only supported on MacOS in JavaFX 2.1. - The MenuBar is part of the scene graph of a Stage, i.e. it has been added to a container under the root of a Scene belonging to a Stage. Other windows such as PopupStage are not supported. - The MenuBar does not not contain any instances of CustomMenuItem other than SeparatorMenuItem. This limitation may be lifted in a future release. At most one MenuBar per Stage will be used for the system menu bar. This is determined by the first instance of the MenuBar skin class that meets the criteria above. Note that skin instances are created in the order processed during the CSS phase. The current implementation also has the following behavior and limitations: - The menus for a Stage will be set on the system menu bar when the Stage becomes focused. If there are multiple stages in the application then the menus will be swapped as each stage becomes focused. - There is no concept of an application wide menu bar at this point, only per Stage menus. - If all stages in an application are minimized, then the most recently set MenuBar remains in the system menu. It may be a good idea for an application on MacOS to have a default hidden Stage (e.g. 1x1 pixel, undecorated with transparency), or for the application to restore the window if the user interacts with the menu bar. - When the MenuBar skin decides to install the menus in the system menu bar, it leaves the MenuBar node still in place with the preferred width and height set to zero. This preserves the scene graph for apps that assume it's there. However, it may leave gaps when placed in common layout containers such as BorderPane and VBox. This can be avoided by placing the MenuBar in a BorderPane or VBox with no spacing, and adding the remaining GUI in another container below the MenuBar. - The "graphic" property of Menu instances is ignored when placed in the system menu bar. - For other instances of MenuItem, the "graphic" property will only be supported if the Node value is an instance of ImageView. It will otherwise be ignored.
17-01-2012
SQE needs RT-18682 done to automate testing of this feature
07-01-2012
We are currently waiting on RT-18056 - so we can use the toolkit API from the controls side.
08-12-2011
Brian, Paru - do you have any update for us? When can you provide the necessary hooks
08-12-2011
OK / SQE Dev needs to provide hooks to enable test automation.
01-12-2011
There is an extra requirement for SQE to be able to automate testing both for FX and for SB and for any other FX application. It should be possible to find current menu state from java code. The way it is done for Swing, JMenuBar and JMenuItem and JMenu components, although invisible, reflect selected/expanded properties which are actually set in Mac OS X native menu. It does not matter whether this would be done the same way in FX or somehow differently as long as a test code is able to determine menu/submenu selection. Rest could be done similar to how it is done in Jemmy v2 for Swing.
30-11-2011
Changing priority from Critical to Major to match priority of PRD item.
23-11-2011
Implements A360 Feature http://oracleplan.oracle.com/gotoEntity?entityType=FEATURE&entityId=747213.
23-11-2011
Also raised by customer: https://forums.oracle.com/forums/thread.jspa?messageID=9942283#9942283
19-10-2011
I am marking this feature as critical since Mac support is now back in our scope (from Platform and Scene Builder perspective), even if only in Beta. Not having a real Mac menu bar is hardly acceptable for a Mac desktop application. We need this feature in update 2.0.4.
04-10-2011
We do not need this one in Presidio for the Visual Tool, obviously since MacOS is not supported, but we'd need this ASAP after Presidio such that the Visual Tool GA can be supported on Mac, with a proper L & F, as soon as possible after Windows.
19-05-2011
mac is not a priority for presidio
04-02-2011
Should now be supported in Prism/Glass
06-12-2010
Reassigning this as the issue is really the lack of support in prism for showing the normal 'mac'-style menubar. This issue can probably be closed as a duplicate or reassigned to me if as a reminder to hook this in once the prism support is in place.
01-04-2010
I'm marking as major because we are still finalizing the menu api, so I want this feature to be considered during the api design, even if we don't build the implementation right away.
28-09-2009