While digging around in the bug database I ran across a bug that was already filed on this issue. I don’t recall it being mentioned during this discussion, my apologies if it was and I just forgot.
https://bugs.openjdk.org/browse/JDK-8231245 Controls' behavior must not depend on sequence of handler registration > On Oct 31, 2023, at 4:05 PM, Andy Goryachev <andy.goryac...@oracle.com> wrote: > > Dear John: > > I am not convinced. I think there is no need for an extra mechanism (I am > referring to waves), the scenario you are describing here > > that when I do `scene.addEventHandler(KeyEvent.KEY_PRESSED)` I won't see > navigation keys because they are all consumed by a focused control. > > should, in my opinion, be implemented via addEventFilter() on the container > or the scene. > > 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. > > Hm. We need two priorities for skins, and if the application side wants to > add a handler that is guaranteed to be invoked first or last regardless of > skin change, we need at least two more. So two priorities are clearly not > enough. > > -andy > > > > > From: openjfx-dev <openjfx-dev-r...@openjdk.org> on behalf of John Hendrikx > <john.hendr...@gmail.com> > Date: Tuesday, October 31, 2023 at 15:10 > To: openjfx-dev@openjdk.org <openjfx-dev@openjdk.org> > Subject: Re: [External] : Re: Prioritized event handlers > > 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> <mailto:mar...@martinfox.com> > Date: Tuesday, October 31, 2023 at 10:13 > To: Andy Goryachev <andy.goryac...@oracle.com> > <mailto:andy.goryac...@oracle.com> > Cc: Michael Strauß <michaelstr...@gmail.com> > <mailto:michaelstr...@gmail.com>, openjfx-dev <openjfx-dev@openjdk.org> > <mailto: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> > <mailto: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> > <mailto:openjfx-dev-r...@openjdk.org> on behalf of Michael Strauß > <michaelstr...@gmail.com> <mailto:michaelstr...@gmail.com> > Date: Friday, October 27, 2023 at 19:41 > To: openjfx-dev <openjfx-dev@openjdk.org> <mailto: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> <mailto: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
