RFR: 8343956: Focus delegation API

[Michael Strauß]

On Sun, 9 Feb 2025 11:31:09 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> > @hjohn I think what's missing in your model is the option to have an independently focusable node inside of a control. For example, think of a Button placed within a Button (via its `graphic` property). Clicking the nested button should not transfer the focus to its parent button. Whether a focus request should be hoisted is a choice that depends on the specifics of the control, and we probably need an API for that.
> 
> Okay, agreed, so it would be good to have Nodes control whether or not the focus traverses up.
> 
> I could imagine the flag could also in the future perhaps allow the Root Node or Scene to determine whether the Window should receive focus (perhaps special cases like popups or transparent overlays would allow interaction without hoisting focus to the Window?)

Do you mean window focus in a JavaFX sense, or in a window manager sense? For example, in Windows you can make a window non-activatable, which means it won't steal the focus from other windows when interacted with (for example, an on-screen keyboard window).


> Then what about the focus delegate? This is not a full FX property in this API, but seems very similar to `focusOwner` in Scene, in that it determines to which `Node` (keyboard) events are directed. One could say that, since Window/Scene are also focusable, Scene is **delegating** events/focus to a node. Would it be reasonable to have `focusDelegate` be a read-only property like in `Scene`, and perhaps rename it to focus owner (or if that's too drastic, ensure that `Scene` at some later stage --might-- implement the same interface and then duplicating its focus owner property as focus delegate)?

It works quite well to say that a `Scene` delegates focus to a `Node`. It doesn't seem to work quite as well (linguistically) to say that a `TextField` is the focus owner of a `ComboBox` (the `ComboBox` is also focused, why would the `TextField` be its focus owner?). But linguistics aside, the question is whether `focusOwner`/`focusDelegate` should be a read-only property.

That's a very good question. It would allow observers to know when the focus delegate changes. But can the focus delegate change? It can probably go from non-null to null, and vice versa. Let's consider a hypothetical control that is like a combo box, but it contains two separate text fields. It seems reasonable that the focus delegate can probably change between the two text fields.

But the proposed API doesn't seem to easily support this scenario. When I click on the second text field, it hoists the focus request up to the combo box, which in turn delegates its focus to... the first or the second text field? How would it choose? Is this a scenario that we need to solve?

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1632#issuecomment-2646469169