Supporting the Mac OS menubar in JavaFX

[steve.x.northover at oracle.com]

Thanks Jonathan.

To put what I meant in concrete terms, it will not be possible to have a 
menu bar on the mac without having at least one stage visible.

Steve

On 14/12/2011 8:06 PM, Jonathan Giles wrote:
> 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