App Kernel: Application Menubar & Lifecycle Events

[Jeff McDonald]

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