On 31/10/2023 21:03, Andy Goryachev wrote:
Dear Martin:
I understand John’s point: you want all the user installed filters and
handlers across all levels to be processed before switching to system
level processing. I also understand this prioritization proposal is
designed to push our existing set of system handlers to a separate
phase. But is that all we’re talking about here? I need some
clarification.
If I understand this correctly, this proposal advocates making drastic
changes to the event handling mechanism. Not only it introduces the
prioritization scheme (which I support), but it also alters the way
events are bubbled up, by introducing waves/phases. I am afraid I
don’t see the use case for doing that. In my opinion, the
prioritization scheme should work on handlers added to the same
EventTarget. There should be no multiple waves - if an event gets
consumed by an event handler, the dispatching should stop (that change
I also support), if not - it bubbles up the hierarchy.
The waves (or calling of registered default handlers at the end) are
needed to also allow users to install handlers at ancestors that would
take priority over system handlers. System handlers really shouldn't
touch events unless they fully bubbled up, so the illusion that user
event handlers are the sole event handlers in existance is being maintained.
The fact that event handler lists are being shared currently is
incredibly confusing, so that when I do
`scene.addEventHandler(KeyEvent.KEY_PRESSED)` I won't see navigation
keys because they are all consumed by a focused control. Instead, I
should be seeing them, and if I choose not to act on them, only then
should those events be used for navigation. The current scheme is very
business orientated (why would you ever not want to have navigation keys
consumed?), while other use cases may simply want to disable keyboard
control altogether (games) or have other more important uses for the
cursor keys (like scrolling a map that does have clickable controls).
Of course, this would need to be done in a backwards compatible way as
it has been this way for quite a while, so sure it you might see it as
drastic, but its compatible, fixes a real flaw in FX event handling
(unpredictability), allows several requested use cases (albeit at a low
level), and its flexiblity will open up new ways of solving problems we
haven't even thought of yet.
Within a given control the order of event processing gets involved. If
a Control is subclassed the subclass should get first shot at the
event. The same is true for Behaviors and Skins. Beyond that I’m still
not clear if the behavior or skin should get the event first or if the
skin should get it via the behavior or the other way around. In any
case, you’ve got the control, the behavior, the skin, and all of their
subclasses trying to sort out the execution order.
Hmmm. I am not sure I understand exactly what you are saying.
The way I understand this prioritization proposal is that we introduce
a priority associated with the handler (and not the filter). The
proposal specifies 3 priority levels, I think there might be more, or
perhaps we even have an int priority (might be too much freedom, let’s
discuss).
Specifically, I think there might be 5 levels, from high to low (the
names are just for the purposes of discussion):
{ AppHigh, SkinHigh, AppMedium, SkinLow, AppLow }
This way there is absolutely no ambiguity in deciding which handler
gets invoked first. I must note that SkinHigh, SkinLow should not be
available to the application code. At the same time,
AppHigh,AppMedium,AppLow levels should not be available to
skins/behaviors.
Side question: should filters also have priority?
I think we're over thinking it. Such fine grained priorities are not
needed. There are two parties involved, the user and JavaFX, hence two
priorities should be enough. FX can be responsible for ensuring its
Skin/Behavior handlers are installed in the right order (they already
have to do that), and users can be responsible for sorting out their own
event handler order (they are after all in full control of that).
Alternatively, we can have no priorities and instead only have a
mechanism that allows event handlers to forego handling an event, but
register an interest in handling it if it is unconsumed (after
dispatching completes for filters, or after bubbling completes for
handler if we're inclined to offer both) -- I call these default
handlers, similar to how there is a default exception handler on each
Thread, each Event can have a (list of) default handlers.
Based on this discussion (and I might be mistaken on this) it sounds
like you're trying to handle all this using this proposal, namely
registering event handlers with a prioritization scheme.
Wait, I though that’s what you are proposing, based on the doc
https://gist.github.com/mstr2/4bde9c97dcf608a0501030ade1ae7dc1
Are you proposing something else, or is something missing from the doc?
Wouldn’t it be easier to just grab the event and pass it around using
Java method calls? Perhaps the call is handleEvent(). A control
implements handleEvent() by passing the event off to the behavior’s
handleEvent() which passes it off to the skin’s handleEvent(). The
skin sends it up the superclass chain by calling super.handleEvent(),
etc. so on.
Wouldn’t this be a drastic departure from the established event
handling method? Why call an empty method if we are not interested in
the event? Or maybe I misunderstood you here, what are you asking?
To summarize, I think the idea of explicit priority is a good idea as
it solves the current issue or exact ordering of handlers in the event
of skin change, to give one example. I think we might also benefit
from a limited set of priorities (5) that reflect the reality of fx
having two sides - the application side and the “system”, or
skin/behavior, side.
Personally, I find some other ideas problematic: I don’t see a good
use case for multiple waves in dispatching, as this represent a major
departure from the current mechanism, unless I am missing something.
I don’t understand the paragraph about subclassing. Perhaps you mean
that if we have a situation where one class extends the other, they
should coordinate the event handling. For example, the base class
would declare the handling method, register it as a listener, for the
child class to override and get the events? Or the base class should
not add any handlers, instead leaving it up to the child class? But
that’s implementation detail.
What do you think?
-andy
*From: *Martin Fox <mar...@martinfox.com>
*Date: *Tuesday, October 31, 2023 at 10:13
*To: *Andy Goryachev <andy.goryac...@oracle.com>
*Cc: *Michael Strauß <michaelstr...@gmail.com>, openjfx-dev
<openjfx-dev@openjdk.org>
*Subject: *[External] : Re: Prioritized event handlers
I understand John’s point: you want all the user installed filters and
handlers across all levels to be processed before switching to system
level processing. I also understand this prioritization proposal is
designed to push our existing set of system handlers to a separate
phase. But is that all we’re talking about here? I need some
clarification.
Within a given control the order of event processing gets involved. If
a Control is subclassed the subclass should get first shot at the
event. The same is true for Behaviors and Skins. Beyond that I’m still
not clear if the behavior or skin should get the event first or if the
skin should get it via the behavior or the other way around. In any
case, you’ve got the control, the behavior, the skin, and all of their
subclasses trying to sort out the execution order.
Based on this discussion (and I might be mistaken on this) it sounds
like you're trying to handle all this using this proposal, namely
registering event handlers with a prioritization scheme. Wouldn’t it
be easier to just grab the event and pass it around using Java method
calls? Perhaps the call is handleEvent(). A control implements
handleEvent() by passing the event off to the behavior’s handleEvent()
which passes it off to the skin’s handleEvent(). The skin sends it up
the superclass chain by calling super.handleEvent(), etc. so on.
This would make for an easy sell to outside developers. We can tell
them that if they subclass a Control and implement handleEvent() they
will get events first during the system phase. The same is true if
they subclass a behavior or skin. They don’t need to buy into or even
see a complicated event prioritization scheme to get exactly what they
expect, namely first access to events.
But, again, maybe I’m off base here. Let me know.
Martin
On Oct 30, 2023, at 12:53 PM, Andy Goryachev
<andy.goryac...@oracle.com> wrote:
Dear Michael:
Thank you, this is very helpful.
Questions/Comments:
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)
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.
3. I wonder if three priority levels are sufficient. Let me
explain. We have two possible actors who can register an event
listener: the application code and the FX (or, rather more
specifically, the skin and its behavior, whatever that might be).
Application code might want to add handlers at three possible
priorities:
* App handler must always be called before any fx handler
* App hander does not care
* App handler must always be called after any fx handlers
For fx/skin handlers we might have fewer levels:
* Skin handler does not care
* Skin handler must be called after all other skin handlers
This situation maps to 5 priorities and 4 effective levels (or 5).
We should also mention the fact that when any actor adds two or
more handlers for the same event with the same priority, they get
invoked in the order added.
Would you agree, or am I missing some critical aspect of the
proposed solution?
Thank you
-andy
*From:*openjfx-dev <openjfx-dev-r...@openjdk.org> on behalf of
Michael Strauß <michaelstr...@gmail.com>
*Date:*Friday, October 27, 2023 at 19:41
*To:*openjfx-dev <openjfx-dev@openjdk.org>
*Subject:*Re: Prioritized event handlers
Here is the proposal:
https://gist.github.com/mstr2/4bde9c97dcf608a0501030ade1ae7dc1
<https://urldefense.com/v3/__https:/gist.github.com/mstr2/4bde9c97dcf608a0501030ade1ae7dc1__;!!ACWV5N9M2RV99hQ!NvO4B-fpHrjczoDGCoctorfNPX48w38MvW-LOf6ElCk0dBqFX_xPlETcr56POnEaBcwENrIOsX4OKDM0OGc07A$>
Comments are welcome.
On Fri, Oct 27, 2023 at 8:21 PM Andy Goryachev
<andy.goryac...@oracle.com> wrote:
>
> Would it be possible to create a proposal in the JEP format
outlining the proposed public API?
>
>
>
> Thank you
>
> -andy
