RFR: 8090456: Focus Management [v8]

[Andy Goryachev]

On Fri, 11 Oct 2024 17:33:00 GMT, Michael Strauß <mstrauss at openjdk.org> wrote:

>>> > My suggestion for a better API is: have two separate knobs to configure directional and logical focus traversal, and provide a very small set of curated policies. We should only consider opening up the API to allow more customization when there is a demonstrable need that goes beyond the curated policies.
>>> 
>>> As I was reviewing the existing JavaFX control set and the w3c guidelines I found at least three different cyclical traversal patterns (menu bars and radio button groups are the two that spring to mind). In all cases the directional and logical traversals behaviors were intertwined. Among the three different ways of cycling (left/right, up/down, and with the tab key) you have to ensure at least one of them allows the user to escape the cycle and each model opted for a different escape route. Cyclical policies are more diverse than one might think.
>> 
>> I don't think they are intertwined. For example, a radio button group will have a directionalTraversalPolicy="cyclic in container" and a logicalTraversalPolicy="single focused node in container" (see [here](https://github.com/openjdk/jfx/pull/1555#issuecomment-2342418714)). As I said before, this requires the addition of another API, namely the "entry point" into a container-like structure.
>> 
>>> If we close up the traversal API we will be on the hook for identifying and implementing all the traversal policies. If a developer needs something more they'll have to petition for it to be included in JavaFX or provide their own PR and try to get it through the review process. That's not a good use of our time or theirs.
>> 
>> This is not a sufficient reason to skip API engineering and just expose an implementation detail, like this PR does. For example, Martin says [this](https://bugs.openjdk.org/browse/JDK-8095467) about `NEXT_IN_LINE` back in 2014:
>>> I also had to introduce special direction NEXT_IN_LINE, which does traverse to the next Node and ignores children of the current Node. This is needed when a Parent's inner traversal for NEXT returns null, we need to traverse from that Parent, but not inside it (which is normally done with NEXT). I don't like NEXT_IN_LINE much, but since it's not a public API (yet), I think we can live with it.
>> 
>> "Living with it" is not good enough for public API, and so far, no one has demonstrated why the API as proposed in this PR is a sensible API in the first place, its raison d'être simply being "it already exists in the internals".
>> 
>>> In any case I don't be...
>
>> @mstr2 could you please explain why
>> 
>> > As I said before, this requires the addition of another API, namely the "entry point" into a container-like structure.
>> 
>> is not covered by `TraversalPolicy`'s `public abstract Node selectFirst(Parent root)`?
>> 
>> I just want to make sure I fully understand your point.
> 
> This point was related to the assumption that there could be two new properties: `directionalTraversalPolicy` and `logicalTraversalPolicy`. Then there needs to be another API that covers the following aspects:
> 1. It indicates which element in a container will receive focus if we traverse into the container.
> 2. It keeps track of the currently focused element within the container, because if the focus is directionally moved to another element in the container, and then logically moved out of the container, we would want to return to the previously focused element within the container if we logically traverse back into the container.

@mstr2 thank you for clarification!

and if we assume that we won't be adding these properties, the use case you describe should be covered by the `TraversalPolicy.selectFirst()/.selectLast()` ?

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

PR Comment: https://git.openjdk.org/jfx/pull/1555#issuecomment-2407859063