App Kernel: Application Menubar & Lifecycle Events

[Richard Bair]

No, Stage is in the same module as Application (you can see it in the sources under javafx-ui-common).

On Mar 6, 2012, at 2:00 PM, Tadashi Ohmura wrote:

> What about this ?
> MenuBar menubar = stage.getHostOSMenuBarBuilder()
> 
> Is it all right that Stage has getHostOSMenuBarBuilder() method ?
> 
> Tadashi Ohmura
> 
> (2012/03/07 3:33), Richard Bair wrote:
>> Before getting into the specifics, the one immediate problem I see is one of modularization. The MenuBar is a UI control, but Application is in a base module. If we have Application depending on controls, then we have a modularization mess. We could create a set of base classes / interfaces for MenuBar etc in the application package which is not a UI control and have the controls extend those, but doing so should obviously be thought through pretty completely because it is going to lead to a wart in the APIs (we don't want two classes with the same name, for example, or duplicated functionality).
>> 
>> Richard
>> 
>> On Mar 5, 2012, at 3:43 PM, Jeff McDonald wrote:
>> 
>>> As part of my discussion on how to handle lifecycle events I've been
>>> working on a related proposal to handle the menubar situation much more
>>> elegantly. Here are my thoughts bellow:
>>> 
>>> Add a new method to the Application
>>> class: Application.getHostOsMenuBuilder(): //Returns a MenuBulder that is
>>> configured to build menus for the host os.
>>> 
>>> MenuBar menubar = Application.getHostOSMenuBarBuilder()
>>> .appName("My App Name")
>>> .preferencesMenu("Preferences", other prams go here)
>>> .quitMenu("Quit",  other params go here)
>>> .aboutMenu("About", other prams go here)
>>>        .addMenu(menu); // Menus are layed out according to  displayed in
>>> the order they are added.
>>> 
>>> The proposal offers the following advantages:
>>> - The resulting MenuBars are structured in the same way that is consistant
>>> with the host platform's UI guidelines.
>>> - The API makes it easier for developers to follow platform guidelines
>>> without having to give up the ability to create completely custom MenuBars
>>> and use those instead.
>>> - The builder pattern also supports localization and allowances for
>>> differences in platform naming conventions (Ex. On the Mac, ending an app
>>> is called "Quit", in Windows it's "Exit". Preferences can be called
>>> "settings" instead. Help can be "?" instead of "Help" Note: sometimes the
>>> help menu is an icon.)
>>> 
>>> Add a new method to the Application class: Application.setMenuBar(menubar);
>>> - Used to set an application menubar instance.
>>> - The Application MenuBar is ignored on host OSes that don't support an
>>> Application MenuBar.
>>> - Remove MenuBar#useSystemMenuBarProperty()
>>> - Remove MenuBar#isUseSystemMenuBar()
>>> - Remove MenuBar#setUseSystemMenuBar(boolean)
>>> Yes, remove those three methods! I have a whole speech on why they should
>>> have never been included in the first place ... ask at your own risk :)
>>> 
>>> Design issues that remain:
>>> - What other parameters are required for each menu item to make them fit
>>> into the supported host OS UIs?
>>> - At the very least Event handlers are one of the parameters that are
>>> needed.
>>> - The issue of event handlers isn't "should event handlers be added" rather
>>> the question is how to integrate application level (and lifecycle events)
>>> be incorporated into a unified event handling mechanism. The motivation
>>> here is some events require centralized management. It's probably easier to
>>> provide an example to illustrate my point:
>>>    The quit action:
>>>        - Multiple components listening for (subscribe to) quit event
>>> notifications is a common user story. If there isn't a centralized ability
>>> to listen to events then developers are forced to register listeners on
>>> every quit event source.
>>>        - A quit event can be published from more than one source. For
>>> example: a host OS can generate a quit event (The MacOS and mobile devices
>>> do this now). The user selects "quit" from the Application MenuBar. The
>>> user selects "quit" from a Scene MenuBar.
>>> 
>>> There's lots of solutions to the multi-event-source multi-event-consumer
>>> need (Event bus, and Actions are a few that have been discussed
>>> previously). The question isn't whether there is a need to address this
>>> issue if lifecycle events a part of the platform; the question is what
>>> implementation offers the best solution.
>>> 
>>> Cheers,
>>> Jeff McDonald
>> 
>> 
>