Provide Quit handler for system menu bar

Tue Sep 20 00:11:40 UTC 2022

I don't see us adding 100s of OS-specific API calls, but even if we did, 
going down the path of exposing them as Mac APIs or Windows APIs, 
doesn't really seem like the direction we want to go. Whatever we do 
needs to balance the desire to integrate with, e.g., the macOS or 
Windows platform with a desire to leave the door open for it to later be 
implemented on the other platform(s). And the most cross-platform way to 
do that from an API point of view is by defining API that delivers the 
desired functionality in as platform-neutral a way as possible. It also 
needs to fit cleanly into the existing API.

So in the specific case of a quit handler, we could define a platform 
API that an app could call to register a handler that gets called if the 
platform quit menu is selected and is able to cancel the Quit 
action(basically, that's what is being proposed). We could decide to 
provide some way for an app to query whether it is supported, but maybe 
we just don't need to worry about it in this specific case. We could 
just document that it will get called when the platform quit action is 
called, if there is such an action on that platform. Other than maybe 
mentioning in the docs that the macOS system menu "quit" action is an 
example of an action that would invoke this, it doesn't need to be 
platform-specific. One question to answer is whether we should just put 
this in the Platform class (where we have other similar "global" 
application state), the Application class (which has the life-cycle 
APIs), or somewhere else (which might make sense if we wanted to define 
an analog to the AWT Desktop class, although the existing Platform class 
already has some APIs like this).

-- Kevin

On 9/19/2022 1:46 PM, Andy Goryachev wrote:
>
> Thank you, Kevin.  Your insightful feedback always pulls the 
> discussion in the right direction.
>
> The initial problem we are facing is access to Mac menu in general and 
> additional API specifically.  I can see a possibility of extending the 
> list of APIs that app devs would want on Mac growing, so there should 
> be a better way to add them.  Using hacks like com.apple.eawt, or 
> system properties is probably not the best solution.  Ideally, there 
> should be away that does not require creative linking of stub classes 
> on non-Mac platforms, i.e. we should be able to use a single code base 
> for all the platforms.
>
> ConditionalFeature might work well internally for openjfx, but I don't 
> think it is a good solution for actually exposing the platform APIs to 
> the user.
>
> So, in order to provide platform-specific API in such a way that still 
> allows for a single code base for multiple platform, and one that 
> potentially scales to tens or hundreds of API calls, I see two solutions:
>
> 1. one start starts with a single entry point, like PlatformAPI, 
> described earlier.
>
> 2. a lookup-based approach, where the client code requests a (possibly 
> fine-grained and narrowly defined) implementation from the system.  
> For example:
>
> IMacMenu impl = PlatformAPI.lookup(IMacMenu.class);
>
> (where IMacMenu is an interface that, in this example, provides access 
> to Mac menu, adding shutdown listeners, and so forth).
>
> if we are on windows, this method either returns null or throws an 
> exception, if we are on Mac, we get a working instance (a singleton or 
> a new instance each time, depending on the circumstances).
>
> This way we are free to extend or version the APIs without modifying 
> the core classes.
>
> PlatformAPI.isSupported(IMacMenu.class) might provide a way to see 
> whether the capability is present.
>
> The platform-specific interfaces like IMacMenu might in turn extend 
> some base interface that provides introspection into common 
> properties, such as version, description, possibly a list of other 
> similar capabilities that the platform supports (may be a number of 
> earlier versions?) and so forth.
>
> What do you think?
>
> -andy
>
> *From: *openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of Kevin 
> Rushforth <kevin.rushforth at oracle.com>
> *Date: *Monday, 2022/09/19 at 09:33
> *To: *openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
> *Subject: *Re: Provide Quit handler for system menu bar
>
> I like the idea of looking at this holistically, even if we do end up 
> adding such features one at a time.
>
> As for how to expose such an API, I don't much like the idea of 
> exposing the underlying platform explicitly unless there is no viable 
> alternative. A better approach is one where a feature is optional 
> based on whether the platform you are running on supports that 
> feature. Especially given, as you pointed out, that features that are 
> only available in one platform today might make their way into other 
> platforms tomorrow. As for how to let an application know whether they 
> can use a particular API, we already have ConditionalFeature, so 
> adding to that would be a reasonable thing to consider.
>
> -- Kevin
>
> On 9/19/2022 9:06 AM, Andy Goryachev wrote:
>
>     Greetings!
>
>     Thank you for proposing a solution, Florian.  I wonder if we
>     should extrapolate the problem further.  Given the fact that app
>     developers always need access to platform specific APIs, be it
>     integration with Mac menu, perhaps we should consider a way to do
>     so in such a way that does not require various tricks.
>
>     For example, we might invent a way to query whether we are running
>     on a certain platform and get the corresponding APIs.  Let's say
>     the class is PlatformAPI:
>
>     These methods allow for querying whether the specific platform
>     APIs are available
>
>     PlatformAPI.isWindows();
>
>     PlatformAPI.isMacOS();
>
>     PlatformAPI.isLinux(); // isUnix()? isPosix() ?
>
>     and these will actually return a service object that provides
>     access to the APIs, or throws some kind of exception:
>
>     IWindowsAPI PlatformAPI.getWindowsAPI();
>
>     IMacOSAPI PlatformAPI.getMacOSAPI();
>
>     the service object returned by one of these methods might provide
>     further information about the platform version, as well as access
>     to platform-specific APIs.
>
>     Another thought is perhaps we ought to think about expanding
>     functionality that became available on every platform in the XXI
>     century (example: going to sleep/hibernate).  Possibly external
>     shutdown via Mac menu or a signal discussed by the OP would be
>     considered as platform-independent.
>
>     What do you think?
>
>     -andy
>
>     *From: *openjfx-dev <openjfx-dev-retn at openjdk.org>
>     <mailto:openjfx-dev-retn at openjdk.org> on behalf of Florian
>     Kirmaier <florian.kirmaier at gmail.com>
>     <mailto:florian.kirmaier at gmail.com>
>     *Date: *Tuesday, 2022/09/13 at 08:11
>     *To: *openjfx-dev at openjdk.java.net <openjfx-dev at openjdk.java.net>
>     <mailto:openjfx-dev at openjdk.java.net>
>     *Subject: *Provide Quit handler for system menu bar
>
>     Hi Everyone,
>
>
>     In one project, we have to handle the quit-logic for MacOS ourselves,
>     when the <quit app> menu entry is used.
>     As background information - this menu entry is set in the
>     class com.sun.glass.ui.mac.MacApplication.
>     It's basically hard coded. Currently, in this project, the menu
>     entry doesn't work in some cases.
>
>     My Solution would be:
>
>     Provide a method "Platform.setQuiteHandler(Supplier<Boolean>)"
>     This handler is called when quit <appname> from the menu is called.
>     If the handler returns true, all windows are closed. Otherwise,
>     nothing happens.
>
>     It would look like the following:
>     ```
>     /**
>      * Sets the handler to be called when the application is about to
>     quit.
>      * Currently, this can only happen on MacOS.
>      *
>      * This handler is called, when the user selects
>      * the "Quit <appname>" from the application menu.
>      * When the provided handler returns true,
>      * the application will close all windows.
>      * If the handler returns false, the application will not quit.
>      *
>      * @param The new quit handler.
>      */
>     public static void setQuitHandler(Supplier x) {
>         ...
>     }
>     ```
>     I've created a ticket for this topic.
>     https://bugs.openjdk.org/browse/JDK-8293700
>
>
>     I've got a working version for this change.
>
>     According to Kevin Rushforth this need a prior dicussion on the
>     mailing list.
>
>     Any opinion regarding this?
>
>     I could provide a pullrequest, if someone is interested.
>
>     Florian Kirmaier
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20220919/0bfcb086/attachment-0001.htm>