App Kernel: Application Menubar & Lifecycle Events

[Jeff McDonald]

There's nothing magical about putting  #getHostOSMenuBarBuilder() in the
application class. Keeping JavaFX modular is important. Is there agreement
that a  #getHostOSMenuBarBuilder() is an ideal solution to building
MenuBars that follow the conventions of the host OS? If there's agreement
then where should the  #getHostOSMenuBarBuilder() method go? I don't know
the organization of the code base well enough yet to offer an informed
suggestion, but perhaps a new class can be added to the components module
that called something like "AppComponents" which lives in the components
module, and that's where all App level components find a common access
point. The AppComponents class could also handle tasks such as window
management. I haven't really thought it through ... just tossing the idea
out.


Cheers,
Jeff



On Tue, Mar 6, 2012 at 3:06 PM, Richard Bair <richard.bair at oracle.com>wrote:

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