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-r...@openjdk.org> on behalf of
Kevin Rushforth <kevin.rushfo...@oracle.com>
*Date: *Monday, 2022/09/19 at 09:33
*To: *openjfx-dev@openjdk.org <openjfx-dev@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-r...@openjdk.org>
<mailto:openjfx-dev-r...@openjdk.org> on behalf of Florian
Kirmaier <florian.kirma...@gmail.com>
<mailto:florian.kirma...@gmail.com>
*Date: *Tuesday, 2022/09/13 at 08:11
*To: *openjfx-...@openjdk.java.net
<openjfx-...@openjdk.java.net> <mailto: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
