Hi Andy,
1. What happened to this proposal?
I've come to the conclusion that we need something like that, but
probably in a different form. My current thinking is that we don't
need prioritized handlers, but merely a way for interested listeners
to say "I'll take this event, but only if no one else wants it".
A possible API could be something like the following:
target.addEventHandler(KeyEvent.PRESSED, event -> {
event.ifUnconsumed(evt -> {
// This will be called after the event has bubbled up
// without being consumed.
});
});
This will allow skins to act on events only if user code didn't consume them.
2. Does it make sense to change the API at the EventDispatcher level
when the problem can be easily solved by the InputMap at the Control
level?
Yes, because javafx.controls is not a core part of JavaFX, and it
should never be. People should be free to create their own controls
implementation, or alternative skinning systems. We need to give them
the tools to do so, and not continue the anti-pattern of shifting core
functionality into javafx.controls and special-casing this module even
more than it is already special-cased.
3. dispatching of events that have been consumed (as mentioned in the
earlier discussion)
Probably not necessary. Once an event is consumed, it's gone; we don't
need to dispatch it further.
4. Problem of creating unnecessary clones of events via Event.copyFor()
Unless there is a clear performance problem, I consider any
fundamental change here as a solution in search of a problem.
Events are usually not so plentiful that we're talking about serious
CPU cycles here. The highest-frequency events are probably mouse
events, and they happen at most hundreds of times per second.
5. If we removed the target, then a listener couldn't discern whether
the event was targeted at the receiving node, or at a descendant of
the node.
On Thu, Nov 7, 2024 at 1:03 AM Andy Goryachev <andy.goryac...@oracle.com> wrote:
>
> Dear Michael:
> What happened to this proposal? I would like to restart the discussion, if
> possible.
>
> More specifically, I would like to discuss the following topics:
>
> the reason the discussion was started was due to "priority inversion" problem
> in Controls/Skins, ex.: JDK-8231245 Controls' behavior must not depend on
> sequence of handler registration. Do we have this problem elsewhere? In
> other words, does it make sense to change the API at the EventDispatcher
> level when the problem can be easily solved by the InputMap at the Control
> level?
> dispatching of events that have been consumed (as mentioned in the earlier
> discussion)
> problem of creating unnecessary clones of events via Event.copyFor(), leading
> to ex.: JDK-8337246 SpinnerSkin does not consume ENTER KeyEvent when editor
> ActionEvent is consumed
> why do we need Event.copyFor() in the first place? why does Event contain
> the target??
>
