Focus delegation API

[Andy Goryachev]

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/20241206/545f5475/attachment.htm>