Supporting the Mac OS menubar in JavaFX

[steve.x.northover at oracle.com]

.. of course I meant "stage" when I said "shell".

Steve

On 09/01/2012 1:45 PM, steve.x.northover at oracle.com wrote:
> Hello!
>
> I believe there are problems with 1) and 2).  First off, there is no 
> way to mix and match.  For example, suppose I want some shells to use 
> the global menu bar and others to use a local menu bar.  Further, 
> application code may put trimmings around a menu bar and when the menu 
> bar is "hoisted up", the window might look strange.
>
> If we are doing 3), I think a better approach would be for the 
> application to decide whether it is using native menu bars or not by 
> explicitly setting a menu bar on a stage.  It makes sense because on 
> platforms like Windows and GTK, there is a one-to-one mapping between 
> stage and menu bar so why not make this explicit in the API?  One of 
> the problems with having API in Stage is that we don't want a 
> reference to MenuBar.  Why don't we define something like 
> Stage.setMenyBarArea() or something like that to take a Node or 
> another type instead?
>
> Steve
>
> On 09/01/2012 1:30 PM, Paru Somashekar wrote:
>> Hello All,
>>
>> The following is the proposal (follow up from previous email by 
>> Jonathan) from UI Controls team towards an API to support native Mac 
>> OS menubar.
>>
>> 1) A new property useGlobalMenuBar would be added to MenuBar class 
>> whose initial value will be set to a default dictated by a property 
>> settable via CSS ( and set to false by default). Once again, for the 
>> first cut of this support in this release, this will be the only 
>> public API for native menubar support.
>>
>> 2) In the case when we have multiple Menubars specified on a stage, 
>> the first one wins and will be made global, i.e. provided the 
>> platform supports native integration and useGlobalMenuBar is set to 
>> true.
>>
>> 3) As mentioned in a previous email by Jonathan, we will have hooks 
>> to switch between stages when they become active and swap menu bars. 
>> In the case when we don’t find a Menubar, it will be nulled out. This 
>> is the path we are choosing for now and we realize that we can change 
>> this later with no backward compatibility issues.
>> We are extending the same concept to the scenario where, when the 
>> last window closes; it will be nulled out as well and hence there is 
>> no concept of a default menubar.
>>
>> thanks,
>> Paru.
>>
>> On 12/14/11 5:20 PM, Kevin Rushforth wrote:
>>> An API on Stage to set a menu bar has a certain elegance, plus it 
>>> gets around the backward compatibility and inconsistency problems 
>>> that having "native" on by default would create. Unfortunately, as 
>>> Rich pointed out earlier, it creates an unwanted dependency from a 
>>> modularity point of view since Stage will be in the base module and 
>>> should not depend on anything in controls.
>>>
>>> -- Kevin
>>>
>>>
>>> steve.x.northover at oracle.com wrote:
>>>> Hello all,
>>>>
>>>> How about an API in Stage where you set the menu bar for the stage? 
>>>> This is the menu that you wish to be native and the application 
>>>> very is clear about this. There can only be one real menu bar on 
>>>> Windows. Application code can ask for the menu bar and add items to 
>>>> it. If you have a property, application code needs to do the same 
>>>> search that FX does to determine if there is an active menu bar.
>>>>
>>>> Here is what I think about focus: On the Mac, when a stage gets 
>>>> focus, it sets the native menu bar. When it loses focus, it clears 
>>>> the native menu bar. Retaining the menu from the previous stage is 
>>>> unlikely to be the right thing to do as an application can have 
>>>> many different stages around and only the application can know 
>>>> whether the current menu bar applies to a stage.
>>>>
>>>> Steve
>>>>
>>>> On 14/12/2011 6: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
>>