Access to private EventHandlers

[Kevin Rushforth]

Yes, this could be useful. I would characterize this as an enhancement 
request to "add additional event handlers" rather than "access private 
event handlers", though. It would be good to be informed by what the 
current implementation happens to do.

As was done when creating the public API for Robot, any new API would 
need to be designed to fit into the existing event framework, probably 
extending from javafx.input.Event. So it's better to think of this in 
terms of coming up with a new API that provides the needed events to 
applications, rather than in terms of moving an existing package-scope 
class to a public package. We likely wouldn't want / need to duplicate 
all of what it in the current interface.

Other considerations to think about:

1) What should the API look like? What will applications do with those 
events?

2) Is this something that makes sense on more than just macOS? And if 
not, how useful is it to most applications? If it's still useful, do we 
need some way at runtime to let apps know whether it is available 
(beyond just documenting that it is platform-specific)?

3) We have an open RFE for adding "desktop" like functionality to 
JavaFX. It's not high on the list of things likely to be worked on, but 
we would want to consider how any new event handler would fit into such 
if/when we ever did it.

-- Kevin


On 12/17/2020 10:57 AM, José Pereda wrote:
> While chasing down an issue on Mac with application events, we have noticed
> that there is some code under a private package that apparently it is
> supposed to be used by developers, which of course it is discouraged:
> com.sun.glass.ui.Application:EventHandler [1] is a public static inner
> class under a private package, that is added to the Application class for
> subclassing.
>
> So far, only QuantumToolkit does subclass it [2] (just for Quit action and
> Theme changed events). However the EventHandler class has more methods for
> listening to MacOS/iOS application events.
>
> While most of those events happen before the app starts (and it wouldn't
> make sense to try to listen to them app-wise), in particular, the
> OpenFilesAction event is forwarded [3] when a second EventHandler is set.
> Other events like resign/become active actions can be listened to as well.
>
> A developer could provide a subclass of such EventHandler if it were public
> API, but so far, that has to be done accessing private API.
>
> At this point, and following on this other thread [4] that discussed a
> similar issue with EventHandlerManager, we should start considering the
> design of new public API that could provide developers with access to such
> events, with considerations to possible platform specifics.
>
> Regards,
> Jose
>
>
> [1]
> https://github.com/openjdk/jfx/blob/master/modules/javafx.graphics/src/main/java/com/sun/glass/ui/Application.java#L45
> [2]
> https://github.com/openjdk/jfx/blob/master/modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/QuantumToolkit.java#L352
> [3]
> https://github.com/openjdk/jfx/blob/master/modules/javafx.graphics/src/main/java/com/sun/glass/ui/Application.java#L346
> [4]
> https://mail.openjdk.java.net/pipermail/openjfx-dev/2020-October/027909.html
>
>
>
> --