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
