App Kernel: Application Menubar & Lifecycle Events

[Tadashi Ohmura]

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
>
>