On Thu, 10 Oct 2024 08:46:25 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. >> >> 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. >> >> 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. > >> > 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 ... @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. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1555#issuecomment-2407789961
