JDK-8090562 : Keeping menu in the Mac menu bar when there is no more stage
  • Type: Enhancement
  • Component: javafx
  • Sub-Component: application-lifecycle
  • Affected Version: 7u6
  • Priority: P3
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2012-02-23
  • Updated: 2018-09-05
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
tbdUnresolved
Related Reports
Blocks :  
JDK-8100982 - Provide ability to alter the implicit "exit on last window closed" behavior
Blocks :  
JDK-8122495 - Remove workaround for RT-19857
Relates :  
JDK-8090985 - System-wide menubar improvements
Relates :  
JDK-8099012 - New Menu API should support concept of a single appwide menubar, and work properly on Mac
Description
When the last stage is closed and a native Mac menu is installed, it would be nice to be able to keep the menu in the MenuBar. This is common behavior for mac Application.

In a Document oriented application, such as the SceneBuilder, we would take benefit of a running JVM and already loaded classes when re-opening a new document.
Comments
Not planned for Lombard
05-12-2012
The only alternative to adding a static method that I can think of, that would solve this issue, is to add a non-static method MenuBar.setAsDefaultSystemMenuBar(). This would not have the same advantage of allowing system MenuBar instances that are not part of the scene graph - except for the default MenuBar.
02-05-2012
SQE: 1 day of work
11-04-2012
A way to solve this in Controls might be to add a public static method like MenuBar.setSystemMenuBar(Stage, MenuBar), where the Stage can be null to signify a default set of menus. This may cause some conflict with the current property useSystemMenuBar, so we need to define how they interact, and which takes precedence.
29-03-2012
Assign the umbrella issue to Leif to drive from the controls team.
28-03-2012
Sure, go ahead.
27-02-2012
The workaround works fine. I used a 0*0 scene, Here is the code: private static Stage keepAliveStage; private static void displayMiniMenu() { assert Utils.IS_MAC; if (keepAliveStage == null) { Group grp = new Group(); Scene scene = new Scene(grp, 0, 0); keepAliveStage = new Stage(); keepAliveStage.setTitle("KeepAliveStage"); keepAliveStage.setScene(scene); MenuBar mb = ApplicationMenu.createMiniMenu(); assert mb.isUseSystemMenuBar(); grp.getChildren().add(mb); keepAliveStage.setResizable(false); keepAliveStage.show(); } }
27-02-2012
I thought at such workaround but sounded a bit hacky. If you propose it, then I can't resist...
23-02-2012
How would this new feature affect the Menu API in controls? Wouldn't it just be a matter of registering a default MenuBar with Application or Platform? We have discussed the possibility of a workaround for the current release, using an "invisible" Stage that stays alive when all others are closed. It could be 1x1, undecorated, and transparent. Maybe you could try this, JF?
23-02-2012
Also this will involve controls and graphics (glass is probably the only related piece that doesn't need to change).
23-02-2012
This is more of an app life-cycle issue than a glass issue. Also, it depends on RT-15011 since the currently specified behavior is for the JavaFX runtime to terminate when the last window is closed.
23-02-2012