On Sun, 9 Feb 2025 18:23:47 GMT, Michael Strauß <mstra...@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?) >> >> 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)? >> >> This can be achieved later, just interested in hearing your thoughts: >> - A getter can later become a property >> - A getter can later become part of an interface >> - Scene can later implement an interface, even if it means duplicating the >> functionality of a property (if not named the same already) >> >> I see some overlap, and having Nodes/Scene/Window implement a common >> interface (like `EventTarget`) is not unheard of. >> >> Again, I love this proposal, and would like to move it forward. > >> > @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 > cl... @mstr2 do you think it is worth pursuing this further? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1632#issuecomment-2815089505
