OK, let's backtrack a bit. consider this example https://github.com/andy-goryachev-oracle/Test/blob/main/src/goryachev/research/ComboBox_Events.java
it's a single combo box with application-level filters and handlers attached to scene, combo box, and the combo box editor. pressing and releasing a key, we get the following output: > user presses 'a' key 1. stage filter: KEY_PRESSED h=913 target=876 2. combobox filter: KEY_PRESSED h=457 target=876 3. stage filter: KEY_PRESSED h=487 target=553 4. combobox filter: KEY_PRESSED h=123 target=553 5. editor filter: KEY_PRESSED h=372 target=553 6. editor handler: KEY_PRESSED h=372 consumed! target=553 7. stage filter: KEY_TYPED h=424 target=876 8. combobox filter: KEY_TYPED h=271 target=876 9. stage filter: KEY_TYPED h=432 target=553 10. combobox filter: KEY_TYPED h=535 target=553 11. editor filter: KEY_TYPED h=208 target=553 12. editor handler: KEY_TYPED h=208 consumed! target=553 13. stage filter: KEY_RELEASED h=336 target=876 14. combobox filter: KEY_RELEASED h=242 target=876 15. stage filter: KEY_RELEASED h=740 target=553 16. combobox filter: KEY_RELEASED h=901 target=553 17. editor filter: KEY_RELEASED h=508 target=553 18. editor handler: KEY_RELEASED h=508 target=553 19. combobox handler: KEY_RELEASED h=955 target=553 20. stage handler: KEY_RELEASED h=232 target=553 ComboBox.onValueChanged: a This output is very puzzling, please help me understand it. - with the exception of events logged from the editor, the events being sent are all different instances (h= prints the event's hashCode) - where did the duplicate event in step 3 come from? step 9? step 15? - why a consumed event is being dispatched to the editor in line 6? line 12? Maybe we should ask the question why in this case the Scene.focusOwner is the ComboBox, and not its editor, the TextField? Having the actual component that receives the input events to be the focus owner would eliminate the need for hacks in the skin to send events, wouldn't it? Or, if we say that's the grand design of javafx - that the skins must forward event copies to the skin constituents, then adding a handler to the top level control (combo box in this case) should result in that handler to be called before the skin's one, right? This, I think, brings us again to the discussion of event handling priority. BTW, you never responded to my questions in https://mail.openjdk.org/pipermail/openjfx-dev/2024-November/050655.html Cheers, -andy From: Andy Goryachev <andy.goryac...@oracle.com> Date: Friday, December 6, 2024 at 11:16 To: Michael Strauß <michaelstr...@gmail.com> Cc: openjfx-dev <openjfx-dev@openjdk.org> Subject: Re: Focus delegation API Returning to this discussion. Consider the following scenario: a compound control such as ComboBox, which has an editable TextField control as a part of its skin. It might be expected that the ComboBox shows the focused border instead of its TextField even when the latter has the input focus. When the user presses and releases a key, the key events are first dispatched to the input focus owner which is the TextField. This part is correct. The issue we seem to be struggling with is that, unlike the case when TextField is used as a top level control, now it is a part of a ComboBox. Which means it should not handle some keys/events, instead delegating them to the top level control - there should be a single "controller" (in MVC parlance), instead of two fighting each other. This statement applies to built-in controls as well as the custom controls. One way to accomplish that is to register a bunch of event filters with the top level control, to prevent the events to arrive at the inner control, forwarding these events to the top level controller, which in JavaFX case is the behavior. The other way which I think will be easier, is to use the proposed InputMap to remove the undesired mappings from the inner control. Doing so does not involve subclassing of the inner controls, since the input map and the mappings will be a public API. With the mappings disabled (or remapped to the functions provided by the top level control), there is no contention between the two anymore. The top level control's controller is in full control, it can do anything that's required to the inner controls - setting pseudo styles, inserting text, etc. As an example - the right arrow key in the combo box's text field can be remapped to a function which checks if the caret is at the last position and then move the focus to the button, if so desired. And if the caret is not at the last position, the default function of text area is invoked - all that enabled by the InputMap. 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:42 To: Cc: openjfx-dev <openjfx-dev@openjdk.org> Subject: Re: Focus delegation API I don't see how these problems are at all related. My proposal solves the focus delegation problem that is inherent with composite controls, which is not even addressed by the InputMap proposal. It also solves an artifact of the event system, namely that key events are delivered to the focused node, which cannot simultaneously be the Spinner and its TextField. The ugly hack to make this work is to duplicate the event entirely, so that if you'd observe Spinner and listen for key events, you will see duplicated key presses. This is also not solved in any meaningful way by InputMap. On Wed, Nov 13, 2024 at 8:33 PM Andy Goryachev <andy.goryac...@oracle.com> wrote: > > I feel this is going in a wrong direction: the root cause of the issues we > are observing, in my opinion, is that the top-level Control is fighting for > control with the inner control, and the inner control's behaves as if it is a > top-level control. > > What should happen instead is to provide a way for the top-level Control to > disable those aspects of the inner control behavior (event handlers, key > bindings) that are not needed anymore, and replace them with the new logic. > Continuing the Spinner example, it is ok for the TextField (Spinner.editor) > to receive events, but the handling of certain key combinations should be > disabled and instead bubbled up to the Spinner behavior. > > I propose to use the InputMap > https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV3.md > for this purpose. > > -andy
