On Sun, 9 Feb 2025 18:23:47 GMT, Michael Strauß <mstra...@openjdk.org> wrote:
> 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?). For what it's worth I am not a fan of using the term focus owner to refer to a focus delegate. The focusOwner of a Scene is the target of key events. The focus delegate of a ComboBox is the *second* target of key events. Key events are sent to the ComboBox first and the delegate only receives the events that it doesn't consume. To me that's an important distinction. But really I just don't want to end up having a conversation about the focusOwner's focusOwner. > 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? Presumably we would need a way of telling the focus scope node which sub-node hoisted the focus so it could select the correct delegate. But it's difficult to imagine a control that's trying to pass itself off as a monolithic entity having two internal TextFields. Wouldn't that require enabling keyboard traversal inside a monolithic control? What does that mean? I don't think this is a scenario we need to solve. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1632#issuecomment-2646621891
