On Fri, 13 Mar 2026 15:54:22 GMT, Marius Hanl <[email protected]> wrote:
>> Michael Strauß has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Avoid variable reassignment > > After I did a deep check on the focus/focus traversable implementation and > usage, I think something like this is 100% needed. > > I just wonder if we can achieve this a bit easier/simple. > > Especially `ScrollBar` and Table related `Controls` had interesting > implementations to 'trap' the focus. > > An easy improvement would be that every `Node` can have a proxy where the > focus should be requested (instead). `ScrollBar` needs it set for whatever > `Control` it should scroll in. The Table Column Header needs that, the > `VirtualFlow` as well, rows and cells as well. But I'm not even 100% sure > about the idea. We probably need to check every case and find the usecase. I > did not checked the `FakeFocusTextField` and related yet. > > The Idea that a `Control` is the top level node that receives focus and > everything else is a black box sounds interesting. But there are controls > that do not request focus at all, like the `Accordion`. There, only the > `TitledPane` will. > > Or a complete different approach: We retrofit the `focusWithin` in those > controls. As far as I could see, the goal was always to have the focus rect > when pressing an inner `Control`. Well, this property is exactly there for > this. And the focus request hacks can be removed. > > Needs more research. I also thought about this issue, and what @Maran23 just said resonates with me. The `Control` is not special. All it brings is `Skin` and a tooltip, otherwise it's a `Region`. What's more, it might be a composite thing: a Control can be constructed out of other Controls, which can be composite as well. So I think it's a bit of a mistake to elevate it to a special place (with regards to focus, in this case). The `Scene` keeps track of a focused **Node**, not a focused `Control`. In the case of a composite Control, it might be some inner Node which may not be a `Control`. And that is how it should be. Event dispatching deals with the focused `Node`, and if a more complex control hierarchy wants to change the way the focus is indicated, it should handle/filter the events correspondingly (focusWithin). The idea of a black-box Control is just a way of saying that Control (regardless of whether it's a simple or a composite one) is just a convenient façade from the application perspective. It allows the application to deal with the complexity without knowing the internals. Does it mean we can bind the outer control's `focused` property to the `focused` property of one of its inner components? I don't know, needs to be investigated. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1632#issuecomment-4056359198
