Getting back to prioritized event handlers.
> I think it would most likely be the latter, i.e. a separate "wave" for
each priority where the event first tunnels down to the target, and
then bubbles back up.
Forgive me, this makes no sense. The point of adding priority to event
handling is to resolve the problem of undefined order in which the handlers
registered on one component are invoked. At least this is where we started.
This is what I expect, really:
scene filter (application)
container filter (application)
control filter (application)
control filter (skin)
control handler (application)
control handler (skin)
container handler (application)
scene handler (application)
This is not what is happening, as was described in
https://mail.openjdk.org/pipermail/openjfx-dev/2024-December/051353.html
I don't know whether any fx internals add event filters/handlers to the scene
or various containers (Parents), but as we know the case of compound controls,
as it is currently implemented, makes the whole picture more complicated:
scene filter (application)
container filter (application)
control filter (application)
control filter (skin)
control forward an event to the skin constituent control filter?
control handler (application)
control handler (skin)
control forward an event to the skin constituent control handler?
container handler (application)
scene handler (application)
> Yes, once an event is consumed, further dispatching stops immediately.
I wholeheartedly agree!
However, this poses a problem: javafx sends out cascades of event copies, often
without looking at whether one event was consumed or not. In my opinion, there
is no need to create copies, meaning the target node should have never been
made a part of the Event (or, if one really wants to keep this paradigm, all
the involved events should have their isConsumed flag bidirectionally bound).
Another thing is the public nature of the EventDispatcher. We spent some time
already talking about it, my issue with it is that is creates two foot-guns:
allows creating custom event dispatchers that can misbehave, and introduces a
parallel mechanism for stopping the dispatch, replacing (or conflicting) with
the existing Event.isConsumed().
I feel these three discussions (focus, EH priority, ifUnconsumed) are basically
parts of the same discussion. It will be rather difficult to resolve all the
issues at the same time, and we don't have to.
I do want to move forward with the input map idea though - I think it brings
benefit to application developers and the skin/custom component developers, so
I want to agree at least on how we should fix the issue of prioritizing event
handling between skins and application. If there are use cases where we might
have undetermined order of handlers outside of controls, then we should think
of adding the prioritization scheme as you proposed. If we only have this
issue in controls, then we could use input map to resolve the issue.
What do you think?
-andy
From: openjfx-dev <openjfx-dev-r...@openjdk.org> on behalf of Michael Strauß
<michaelstr...@gmail.com>
Date: Wednesday, November 20, 2024 at 14:36
To:
Cc: openjfx-dev <openjfx-dev@openjdk.org>
Subject: Re: Prioritized event handlers
Hi Andy!
> 1. Does this proposal changes the way events are dispatched with respect to
> priority? In other words, does it first go through the list of all handlers
> registred on the leaf Node (high priority first, then lower, then lowest),
> then bubble up? Or do they propagate upwards looking for high priority
> handlers first, then the process restarts for lower priorities, as I saw in
> some previous emails? (I could be mistaken)
I think it would most likely be the latter, i.e. a separate "wave" for
each priority where the event first tunnels down to the target, and
then bubbles back up. The downside of this is the increased
implementation complexity: we probably don't want to increase the
number of events five-fold, especially when most of the time, no one
is listening anyway. So there would have to be quite a bit of
optimization to make this work efficiently.
> 2. Do you propose to abort event dispatching immediately after the event is
> consumed? This probably should be mentioned earlier in the Motivation (the
> problem statement) section.
Yes, once an event is consumed, further dispatching stops immediately.
We also need to fix the bug that is currently in FX where that's not
the case for listeners on the same node.
The rest of the questions are very specific for prioritized event
handlers. But I now think that unconsumed event handlers are a much
simpler solution to the problem, as it solves the same set of problems
that are solved with prioritized event handlers.
