New properties: focusOwner and focusOwnerWithin

John Hendrikx john.hendrikx at gmail.com
Sun Oct 8 08:10:47 UTC 2023


I would be interested to know what use cases for these are, and what 
would be then left of the use cases for the existing focusWithin and 
focusVisible properties?  The ticket referred doesn't give one and only 
reports a bug.

Before implementing a second set of these types of properties, I would 
like to know:

- What would be the distinct uses for focusOwnerWithin vs focusWithin, 
are both actually needed?
- Isn't focusOwnerProperty basically a "better" focusedProperty now 
because of how focusedProperty is abused by some controls?
- Why indeed is TableView doing this and should it really be doing this 
instead of doing this another way?  If it just wants to show nodes in 
their focused style, that can (and should IMHO) be achieved differently.

There seems to be a need to have some controls retain their focused look 
without them actually being the focus owner. TableView seems to be one 
of them, and I personally have another (I would like Nodes to keep 
looking focused even when their Stage has lost focus). The focused look 
relies on the `focused` pseudo class, which is now strictly controlled 
by the focusedProperty. It may be a good idea to look in another 
direction; one could change the style sheet for example to also have 
controls in focused look when they have a different pseudo class, say 
`fake-focused`.  TableView could then use this (and so could I).

With the TableView problem solved, the original focusWithin, 
focusVisible and focused properties then can serve the purposes they 
were intended for, instead of basically replacing them with a new set 
that acts slightly differently to work around a problem with TableView.

If this does move forward though, I wonder why these need to be 
properties specifically, given how hesistant we were to add properties 
to Node?  The `shownProperty` which IMHO has far more uses given the 
essential role it can play in deterministic clean-up was rejected over 
such an argument.  Why isn't simply checking the psuedoClassState 
sufficient for these properties: 
`getPseudoClassStates().contains(FOCUS_OWNER_PSEUDOCLASS_STATE)`?

--John

On 07/10/2023 23:00, Michael Strauß wrote:
> JavaFX has two closely related focus concepts: `Node.focused`, which
> can apply to any number of nodes in a scene graph, and
> `Scene.focusOwner`, which is the single node in a scene graph that
> accepts user input.
>
> JavaFX 19 added `Node.focusWithin`, which is a flag set on any node
> that contains a `focused` node. However, there is no flag on `Node`
> for the single focus owner, and also no flag that is set if a node
> contains the single focus owner.
>
> Tickets like [0] show that there might be a need for these additional
> flags. One could argue that it might not be the best idea to set the
> `focused` flag on a node that is not the focus owner (TableView does
> this quite a lot), but I think that ship has sailed.
>
> I've prepared a draft PR [1] that shows the proposed API of this
> enhancement. The functionality can in theory be implemented by
> applications, since the `Scene.focusOwner` property is already
> available, but this is far from easy (especially when CSS is
> involved).
>
> I'm interested in your thoughts on whether this is an API that we want
> to have in JavaFX.
>
> [0] https://bugs.openjdk.org/browse/JDK-8317426
> [1] https://github.com/openjdk/jfx/pull/1255


More information about the openjfx-dev mailing list