Supporting the Mac OS menubar in JavaFX
jonathan.giles at oracle.com
Fri Dec 9 16:38:59 PST 2011
Just as a further data point to what Jim is saying: the
javafx.scene.control.Menu* classes (MenuItem, and subclasses Menu,
RadioMenuItem, CheckMenuItem, CustomMenuItem and SeparatorMenuItem) are
not actually Controls. The only Menu* class that is a Control is MenuBar.
From this perspective, it is actually unfortunate that these
non-Control classes actually live in javafx-ui-control, as they may be
totally suitable in the abstract sense that Jim discusses.
On Saturday, 10 December 2011 10:19:00 a.m., Jim Graham wrote:
> If this was simply a skinning technique of "moving the Stage's menubar
> to the screen's menubar" that works if you have a window open, but it
> doesn't solve the problem of what happens when you have no windows
> open when Mac applications typically still manifest menus in the
> screen menubar.
> Sticking a "separate but equal" menubar somewhere would lead to
> applications failing to look like native Mac apps until the developers
> are made aware of the issues and require "extra" coding to deal with
> Mac deployment.
> If we could provide a way to specify:
> - Here are the menubar items that apply to all windows.
> - Here are the additional menubar items that apply to a specific window.
> - To be most flexible, the "additional items" might have to be
> additional items in the top-level menus that were specified for all
> - Would there also be a need to specify "but not these items" for some
> windows to delete some items that only make sense when no windows are
> Then it would be both an API for letting the runtime know which
> menubar items should remain after the last window closes on Mac, and a
> way to be able to populate lots of window menubars when an application
> has multiple windows.
> The actual manifestation of the menubar would be a control, but the
> specification of what items are needed could be in an independent
> format that doesn't bring in a whole new package. We could create
> skeleton "menu-ish-bar-ish-item" classes in the application package
> and those could be the data that the Menu* controls take, but one
> could attach a list of those to an Application object without having
> Application depend on controls. A Stage could then take an additional
> list and combine it with the list on the Application to make the full
> menu bar list which is then skinned by the controls.
> When no windows are open, then the Mac-specific application could
> still skin them in a native skin and deploy them on the screen
> menubar, or have a hidden dependency on the controls for that platform
> That's a fairly loose conceptual hand-waving outline, but maybe it
> could dislodge a more concrete design from someone more familiar with
> how all of those objects interact?
> On 12/9/2011 3:46 PM, steve.x.northover at oracle.com wrote:
>> Many toolkits have supported portabilitly between Mac and Windows (and
>> other operating systems that put the menu bar in the window) by swapping
>> the menu bar on stage focus in and out. This is what SWT does. Recently,
>> an app wide menu bar was added to support the Mac.
>> On 09/12/2011 6:34 PM, Tom Schindl wrote:
>>>> Another place to specify a MenuBar would be on Stage, rather than
>>>> (or in
>>>> addition to), Application. Having a MenuBar property on Stage would
>>>> allow for the MenuBar to change based on the currently focused Stage -
>>>> but I'm not certain this is desirable or even the expected
>>>> behaviour of
>>>> Mac OS. Therefore, I'm thinking that this is not likely to happen
>>>> we hear otherwise.
>>> Well the menu changes definately based upon the focused top-level
>>> window. So I'm quite sure the MenuBar has to be specified on the Stage
>>> I'm wondering though how you'd like to support all the themeing stuff
>>> one is able to apply on menus/menuitems on OS-X.
>>> IIRC I recently read in a mail from Mike Swingler that one can
>>> arbitary Java Drawing post-Leopard but I'm not sure that matches the
>>> OS-X Menubar idea and all the fancy things one can do with JavaFX.
More information about the openjfx-dev