Some comments in line.
On 09/11/2024 02:52, Michael Strauß wrote:
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.
Yeah, this similar to what Scene does, it waits for events to bubble
back up, then handles navigation or default buttons. Having a mechanism
to hook into this may be a good idea.
We may not need this if there is a way to easily change and replace
Behaviors separate from Skins, as the users would then have the option
to replace or alter a Behavior if the standard one interferes with a
specific event they're interested in. Currently there is little
recourse when this happens, as you'd have to replace the entire Skin to
do such a change.
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.
The target is also not the biggest problem. The source changes much
more often (as can be seen also in your focus delegation document). I
however agree with the assessment that these few copies are simply not a
problem at all.
--John
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??
