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-r...@openjdk.org> on behalf of
Florian Kirmaier <florian.kirma...@gmail.com>
*Date: *Tuesday, 2022/09/13 at 08:11
*To: *openjfx-...@openjdk.java.net <openjfx-...@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
