On Fri, 11 Oct 2024 17:33:00 GMT, Michael Strauß <mstra...@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
