App Kernel: Application Menubar & Lifecycle Events
deep.blue.6802 at gmail.com
Wed Mar 14 03:00:32 PDT 2012
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
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
> >> 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
> >>> 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
> >>> the order they are added.
> >>> The proposal offers the following advantages:
> >>> - The resulting MenuBars are structured in the same way that is
> >>> 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
> >>> and use those instead.
> >>> - The builder pattern also supports localization and allowances for
> >>> differences in platform naming conventions (Ex. On the Mac, ending an
> >>> is called "Quit", in Windows it's "Exit". Preferences can be called
> >>> "settings" instead. Help can be "?" instead of "Help" Note: sometimes
> >>> help menu is an icon.)
> >>> Add a new method to the Application class:
> >>> - 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
> >>> 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
> >>> 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"
> >>> the question is how to integrate application level (and lifecycle
> >>> 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
> >>> 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
> >>> 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
> >>> 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
More information about the openjfx-dev