Prioritized event handlers

[Andy Goryachev]

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-retn at openjdk.org> on behalf of Michael Strauß <michaelstrau2 at gmail.com>
Date: Wednesday, November 20, 2024 at 14:36
To:
Cc: openjfx-dev <openjfx-dev at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20241209/786dcdeb/attachment-0001.htm>