Supporting the Mac OS menubar in JavaFX

Jim Graham james.graham at
Mon Dec 12 14:42:14 PST 2011

Hi Jonathan,

On 12/11/11 4:33 PM, Jonathan Giles wrote:
> @Zonski, @Michael, @Sven:
> I agree that there are a number of places where integration with the
> operating system can be stronger. I'm also very keen to see these areas
> improved upon. As is always the case, if you don't see the features
> you've mentioned in our Jira tracker, I highly recommend that you go
> ahead and file these feature requests.
> For JavaFX 2.1, which is already fairly far into development, the goal
> is just to have Mac OS menubar integration. As you can imagine there is
> a lot of work exposing this native integration in API - it requires work
> down the entire JavaFX stack. This is being developed for 2.1 directly
> based on feedback from consumers of the JavaFX 2.0 API. Future releases
> will certainly take into account feedback you provide in much the same
> way (so please get it into Jira!!) :-)

I think it bears a bit more discussion while we are finalizing the Macos 
menubar support than simply "record your concerns in Jira and we'll get 
to them later".

> The main information I'm after right now is the implications of the
> decisions we make now with regard to native Mac OS menubar support. From
> where I'm sitting, I can't see anything we will come to regret in 2.2
> and future releases. The same API can be used in a future Ubuntu
> scenario, and entirely different API will need to be developed for
> features such as system tray support and Windows 7 task list support. I
> don't get any feeling of concern about regretting this general
> I missing anything?

If we don't have the discussion then all we have is a gut feel for now. 
  Most of these issues were just added to the discussion right before 
you posted this message.  The best practice would be to draw up the 
design for all of these possibilities and then only implement the MacOS 
menubar pieces of it.  Failing that, are we really far enough into the 
discussion to have that strong of an understanding?


> -- Jonathan
> On 10/12/2011 9:32 p.m., Dr. Michael Paus wrote:
>> Hi,
>> I agree with Zonski that there is more to look at than just the menu
>> bar. In order
>> to get some ideas it might be interesting to look at what apple or others
>> recommend now for making Swing apps look more native on MacOS.
>> A good introduction can be found here:
>> <>
>> Going through this document you will see that there are more things
>> that we should
>> consider which go beyond the pure placement of the menu bar.
>> Michael
>> Am 10.12.2011 05:46, schrieb Daniel Zwolenski:
>>> Can I throw a few more bigger picture things into the murky puddle of OS
>>> menu bars and integration. I'm not saying these are all directly
>>> related to
>>> the problem at hand or even are things JFX should be solving, but I
>>> think
>>> floating them past the think tank in the context of this conversation is
>>> not an unhealthy thing to do:
>>> * In windows 7 (and possibly other versions, not sure), if I right
>>> click on
>>> the icon in the task bar it gives me an application-specific menu,
>>> which I
>>> think is not completely dissimilar in usage to the application-level Mac
>>> toolbar options (i.e. the ones that are left after you close all the
>>> windows).
>>> * Windows also has the 'system tray' thing for 'background-style'
>>> applications. Right-clicking on an icon in this brings up another
>>> menu that
>>> is application related.
>>> * OS variations are not the only issue. There is Applet vs
>>> Application to
>>> think about. This whole toolbar thing is only relevant in true
>>> desktop apps
>>> (as far as I can see) so Applets (even on Mac) need to have their rules
>>> defined.
>>> * iPhone/iPad and Android all have their own 'os' specific menu systems
>>> that are similar but not completely the same as the mac window. If the
>>> mobile support for JavaFX happens (please, please, please), then a
>>> menu API
>>> will be needed for this that doesn't look totally dissimilar to the
>>> mac one
>>> again. Over-future proofing can be a problem, but being generally
>>> aware of
>>> likely future directions can be healthy. In Android it is the 'options
>>> menu' and in
>>> iPhone/iPad it is the 'navigation toolbar'
>>> As I said, just food for thought rather than direct issues in need of
>>> solutions.
>>> On Sat, Dec 10, 2011 at 1:55 PM, Jim Graham<james.graham at>
>>> wrote:
>>>> Could the classes be copied to javafx.application, the old classes made
>>>> into empty subclasses of the copies, and then the signatures on the
>>>> methods
>>>> that accepted them be relaxed to the supertype? (Possibly might have to
>>>> have duplicate methods if that isn't binary compatible?)
>>>> ...jim
>>>> On 12/9/2011 5:57 PM, Richard Bair wrote:
>>>>> Ya, that's the bummer. We exactly designed the menus for the exact
>>>>> usage
>>>>> Jim describes, but didn't put them in a suitable package for
>>>>> modularization. Drat!!!
>>>>> On Dec 9, 2011, at 4:38 PM, Jonathan Giles wrote:
>>>>> 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.
>>>>>> --
>>>>>> -- Jonathan
>>>>>> 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
>>>>>>> windows
>>>>>>> - 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
>>>>>>> open?
>>>>>>> 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
>>>>>>> only.
>>>>>>> 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?
>>>>>>> ...jim
>>>>>>> On 12/9/2011 3:46 PM, steve.x.northover at 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.
>>>>>>>> Steve
>>>>>>>> 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
>>>>>>>>>> unless
>>>>>>>>>> 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
>>>>>>>>> not?
>>>>>>>>> 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
>>>>>>>>> implement
>>>>>>>>> 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.
>>>>>>>>> Tom

More information about the openjfx-dev mailing list