RFR: 8090456: Focus Management [v8]

[Michael Strauß]

On Thu, 10 Oct 2024 00:12:54 GMT, Martin Fox <mfox 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 believe that we need to protect developers from themselves. Presumably they're a smart bunch. If you're concerned they won't get it right make sure there's ample documentation and sample code.

I'm not concerned about the proficiency of JavaFX developers, I'm concerned about convincing ourselves that since we don't have the time to do it right, we should just rush out clearly undercooked APIs.

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

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