Access to private EventHandlers
kevin.rushforth at oracle.com
Wed Dec 23 22:56:33 UTC 2020
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
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.
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  is a public static inner
> class under a private package, that is added to the Application class for
> So far, only QuantumToolkit does subclass it  (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  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  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.
More information about the openjfx-dev