I'd like to understand that too, though the question here might be a slightly different topic (maybe for a separate mail thread).
The way I look at the problem of using controls as part of other controls (e.g. a TextField inside a Spinner) is that the inner is no longer a fully functional control, in the sense that it's behavior is different, and governed by the parent control. I tried to clarify the separation between various parts in my InputMap proposal (we are not discussing that yet), look at the table in the "Description" section https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV3.md Basically, the control is a façade that hides its internal structure. So when the application is dealing with the Spinner, it should not deal with the TextField, unless there are public APIs in the Spinner just for that. How the Spinner works is determined by its skin - which can be anything, it can be a 3D knob in some virtual reality with no TextField whatsoever! (Not the case of Spinner, as it actually publishes the TextArea via its getEditor() API. So when we decide to use TextField in a specific SpinnerSkin, we need to modify the way the TextField (being a part of the whole and not the whole) reacts to the external events. The same goes for decorations, including focus decorations. To show the focused spinner we now draw the focus border around the spinner, not the TextArea. So we need a way to reconfigure the event handling behavior of the TexTField used inside of the Spinner. Using the InputMap, it's easy to do without subclassing, by simply modifying the InputMap of the inner TextArea. Right now, we have to jump through a number of hoops with colorful names like setFakeFocus() and so on. What I am trying to get to is that, once the control is a part of another control, it's behavior ("controller" in terms of MVC paradigm) changes, may be even gets substituted by the "controller" of the parent Control. The parent Control is solely responsible for the new behavior, or we going to have tug of war between two parties. I guess my point is - we need a way to customize the behavior, it's useful to both application developers, custom control developers, and the internal skin design, and it's really easy to do with an InputMap. What do you think? -andy From: openjfx-dev <openjfx-dev-r...@openjdk.org> on behalf of Nir Lisker <nlis...@gmail.com> Date: Tuesday, November 12, 2024 at 10:47 To: Kevin Rushforth <kevin.rushfo...@oracle.com> Cc: openjfx-dev@openjdk.org <openjfx-dev@openjdk.org> Subject: Re: Prioritized event handlers I'd like to understand the focus and event handling problem better. If I have a focused TextField, all key events go to it. If I have a Spinner, which is a TextField with 2 Buttons, it is focused as a single unit and consumes key events whether they are aimed at the text field or the buttons (I assume the buttons handle arrow up/down keys?). If I have a ClolorPicker, it is not focused as a single unit - it has sliders, buttons, text fields and other things, which can be focused individually. What I'm trying to find out is what is "the primitive" in the focus/event handling plan. A TextField and a Spinner are treated as primitives, but a ColorPicker and a DatePicker are not. Where does the line pass? If I'm a controls author, can I create a Spinner that allows focusing/event-handling the text field and the buttons separately, like ColorPicker allows? In this case, Spinner is not a "primitive" control. On Tue, Nov 12, 2024 at 7:56 PM Kevin Rushforth <kevin.rushfo...@oracle.com<mailto:kevin.rushfo...@oracle.com>> wrote: I think this is a good discussion to continue. I have a a couple quick comments: The first question I would like to resolve is to determine whether the problem exists globally, or only at the controls level. If even once scenario exists that does not involve controls, we must find a solution at the event dispatch level. If not - the solution can be at the controls level, and I have proposed a good solution, but it's premature to talk about it right now. Unless it can be clearly shown that this is a controls-only problem, and never will be something that other users of events need to worry about, I favor a solution in the event handling mechanism itself rather than something controls-specific. So I agree with Michael on this point. 4, 5. there seems to be general misunderstanding why I see copyFor() as a big problem. (Performance is **not** the issue here). Very likely. I certainly don't see it as a big problem, which suggests I might be missing something. I do find it unlikely that we are going to change something as fundamental as having a target in the event (which is the main reason for using "copyFor"). -- Kevin On 11/12/2024 8:27 AM, Andy Goryachev wrote: Thank you Michael for answering my questions! I get from your answers that: 1. the priorities are still needed, in one form or the other. Adding a different type of the EH (ifUnconsumed) seems to me like a different priority. 2. the problem seems to exist only at the controls level - nothing was mentioned to cause issues related to priority outside of controls. This seems right, because only in controls we have two (or more) actors engaged in event handling - the application and the skin. 3. dispatching consumed events looks like a bug to all respondents 4, 5. there seems to be general misunderstanding why I see copyFor() as a big problem. (Performance is **not** the issue here). Please correct me if I summarized it incorrectly. Another interesting observation is that proposals seem to have been replaced by widely different alternatives - ifUnconsumed and event filters. This might indicate that there is no consensus as of yet, and the discussion must therefore be continued. The first question I would like to resolve is to determine whether the problem exists globally, or only at the controls level. If even once scenario exists that does not involve controls, we must find a solution at the event dispatch level. If not - the solution can be at the controls level, and I have proposed a good solution, but it's premature to talk about it right now. So I would like to ask for clarifications on these three questions: 1. For ifUnconsumed idea: how will it work when both the application and the skin register ifUnconsumed EH? Or is it only available to one side, but not the other? 2. For event filter in behaviors idea: how does it work when both behavior and the application register an event filter? and then the skin is changed? wouldn't we have the same issue? 3. Are there any examples outside of controls where priority inversion happens, or where we need explicit EH priorities for other reasons? 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, November 8, 2024 at 17:52 To: Cc: openjfx-dev <openjfx-dev@openjdk.org><mailto:openjfx-dev@openjdk.org> Subject: Re: Prioritized event handlers 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. 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. On Thu, Nov 7, 2024 at 1:03 AM Andy Goryachev <andy.goryac...@oracle.com><mailto: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?? >
