Supporting the Mac OS menubar in JavaFX

[Jonathan Giles]

Just to clarify Steve's question (on his behalf): he was asking whether 
there was an intention to expose API to developers that would allow for 
them to directly manipulate the Mac menu bar, or whether we would only 
allow for indirect manipulation via the menubar itself.

The answer is, at this stage, that direction manipulation will not be 
exposed in 2.1.

Also, there is a new proposal coming shortly that aims to overcome the 
modularity issue mentioned previously, and to allow for more of what 
Jim and Daniel are discussing. This will be summarised in a separate 
email.

-- Jonathan

On Thursday, 15 December 2011 10:56:54 a.m., 
steve.x.northover at oracle.com wrote:
> Hey Jonathan and all,
>
> Are we also the global Mac menu bar also on the table or should we 
> just defer that?
>
> Steve
>
> On 14/12/2011 7:26 PM, Jim Graham wrote:
>> What happens when the last window closes and a "native" Mac app would 
>> still have a menubar? Where do you find the first menubar marked 
>> native when there are no stages or scenes to search?
>>
>> Also, most of the stages in a single application would tend to have 
>> the same skeleton of the menu bar with only minor variations.
>>
>> Those 2 reasons were why I was proposing adding an app-global menu 
>> skeleton in the Application object - so it could be there when there 
>> are no windows open, and also to share the specification of the base 
>> menu structure between multiple windows in an app...
>>
>> ...jim
>>
>> On 12/14/11 3:31 PM, Jonathan Giles wrote:
>>> Hi All,
>>>
>>> Here's an update from the UI controls team as to how we see the native
>>> Mac OS menubar support working. Your thoughts are appreciated.
>>>
>>> After discussing it again today, we think that the approach 
>>> suggested by
>>> Richard in an earlier email in this thread makes the best sense, in
>>> terms of modularity and code cleanliness. I'll explain this further
>>> shortly...
>>>
>>> The thinking is to add a new property to javafx.scene.control.MenuBar.
>>> We haven't settled on a name, but it's something along the lines of
>>> 'native', 'global', 'globalMenuBar', 'screenMenuBar', or
>>> 'applicationMenuBar'. Whatever property name we use, we'll expand it 
>>> out
>>> to have the usual set*/get*/*property methods. This would be the only
>>> public API we end up adding for native menubar support. For the
>>> remainder of this email I refer to this property as 'native'.
>>>
>>> This property will by default be true, indicating that on platforms
>>> where we support native integration, it'll happen by default.
>>>
>>> On a platform that supports native integration, we'll find the 'first'
>>> MenuBar in the scene that has the 'native' property set to true. We
>>> can't guarantee that we'll find necessarily the physically top-most
>>> MenuBar as that is really a matter of how the scenegraph is laid 
>>> out. Of
>>> course, this is only a problem in situations where the scene contains
>>> multiple MenuBars where 'native' is true in more than one of them, 
>>> which
>>> we hope won't often be the case. If a Scene does have multiple MenuBars
>>> with 'native' set to true, the behaviour is undefined. If the wrong
>>> MenuBar is made native, you can help provide a hint by setting 'native'
>>> to false in the relevant place(s).
>>>
>>> We'll also hook into the Stage and listen to the relevant events, such
>>> that when a Stage gains focus, we'll switch in any native menubars 
>>> found
>>> in the scene of that stage. If no relevant MenuBar is found, then we 
>>> can
>>> either retain the MenuBar from the previous stage, or null it out. I'm
>>> going to assume the former is by far going to win this vote, but feel
>>> free to surprise me.
>>>
>>> Using this approach, developer code should be cleaner. Your user
>>> interface should position a MenuBar where it makes sense for your
>>> application, regardless of the operating system (normally at the very
>>> top of your scene). On platforms where native integration is supported,
>>> the JavaFX-rendered MenuBar will not be rendered (although it'll likely
>>> remain in the scenegraph as a no-op control). If the 'native' property
>>> changes, we'll flick between the native and JavaFX-rendered MenuBar as
>>> expected. This approach means there is no operating system dependent
>>> code in your user interface.
>>>
>>> As I mentioned - we're totally open to discussion on any of these
>>> points. Any thoughts?
>>>
>>> -- Jonathan
>>>
>>> On 10/12/2011 8:56 a.m., Jonathan Giles wrote:
>>>> Hi all,
>>>>
>>>> One of the things we're planning to support in JavaFX 2.1 is the
>>>> native Mac OS menubar. This email is intended primarily to discuss the
>>>> API one expects to see to set a MenuBar in the native Mac OS menubar
>>>> area. Your feedback is sought and will be very much appreciated.
>>>>
>>>> The current thinking is that Application feels like the right place to
>>>> specify a global, application-wide javafx.scene.control.MenuBar on. It
>>>> could be assumed that if a developer were to set this property, and
>>>> the operating system upon which the end-user was running the JavaFX
>>>> application was Mac OS, that the menubar will be displayed using the
>>>> native Mac OS menubar. Of course, if a developer wants a
>>>> cross-platform look and feel, they could just place the MenuBar in the
>>>> stage as per usual and it would display as it currently does. This
>>>> approach opens up a number of questions and issues:
>>>>
>>>> 1) What happens in the case of the end-user being on Windows? Is the
>>>> Application.MenuBar ignored, or is it automagically added to the main
>>>> Stage? (I would argue for totally ignoring it....but that leads to the
>>>> next point).
>>>> 2) This approach means there needs to be operating specific code in
>>>> the UI to test whether a non-native MenuBar should be added (in the
>>>> case of Windows, for example). This starts to clutter the UI code, and
>>>> without careful consideration by the developer may result in needing
>>>> to duplicate their MenuBar code. Is there a better approach?
>>>>
>>>> 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.
>>>>
>>>> Like I said, we're at a very early exploration point in this process.
>>>> The controls team is very keen to hear feedback from the community, as
>>>> well as from the owners of the Application API, and the Mac OS experts
>>>> on this list.
>>>>
>>>> Thanks,
>>>> -- Jonathan