Focus delegation API

[Andy Goryachev]

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