App Kernel: Application Menubar & Lifecycle Events

[Richard Bair]

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