On Wed, 11 Sep 2024 15:06:07 GMT, Andy Goryachev <ango...@openjdk.org> wrote:
> The default one seems to be geometry-based ("directional") _where supported_,
> and the other being a "logical" one which is not explicitly accessible. The
> question, therefore, is do we need a static getter for that kind of a policy?
> (I'd say no since the logical order depends on a particular control).
I don't quite understand what you mean by "not explicitly accessible". Both
categories are exposed with the `TraversalDirection` enum: `UP`, `DOWN`,
`LEFT`, and `RIGHT` are the directional modes, whereas `NEXT`, `NEXT_IN_LINE`,
and `PREVIOUS` are the logical modes.
I think that disentangling those two categories, and having a set of predefined
traversal policies that can be set independently for both of those, will be
good enough for 99% of cases. The reason I'm bringing this up is that
`Algorithm` (now `TraversalPolicy`) is too low-level to be useful for most
application developers. _We_ should be implementing those algorithms, and then
allow developers to compose them as they see fit.
When I look at the existing code, I see quite a lot of bespoke `Algorithm`
implementations. For example, `ToolBarSkin` has almost 100 lines of code
dedicated to a custom implementation. However, when I just remove this
implementation entirely, I get _almost_ the exact same focus traversal
behavior, even in complicated scenarios like when a toolbar item is itself a
focus-traversable container.
This suggests to me that we shouldn't encourage the proliferation of even more
bespoke implementations, but make it easier to compose well-tested existing
algorithms.
>
> A couple of points:
>
> 1. setting via CSS is not a goal (I probably should mention this in the JEP)
> 2. the 4-item enumeration is not complete. For example, application may
> specify some other, or even dynamic, order of traversal, which would require
> a custom policy.
We can add scenarios to this list if it is not complete, and then see if we
still need the option to create a custom traversal algorithm. My point is that
the API should be tailored to be simple and useful in 99% of cases, and then
maybe have an additional extension point for the rest. Right now, you're
proposing to expose the lowest-level API which requires developers to reason
about the scene graph and find individual nodes, which I think should be
reconsidered.
When I look at various JBS issues and browse StackOverflow, I notice that most
developers are only looking for pretty simple things like cyclic traversal in a
container. It's probably prudent to tailor the API for those use cases.
>
> Another question is whether there exists a policy that cannot be implemented
> by the new APIs provided by this PR.
>
> What do you think?
Since the API works directly on the scene graph, you can probably create all
kinds of algorithms with it. The downside of that is, however, that all
implementations are ad-hoc solutions that don't generalize. For example, the
radio group I mentioned earlier suggests that we should have an API to define
an "entry point" into a container of nodes. You can do that with a custom
implementation, but I think having this be elevated to a proper API would be
better.
-------------
PR Comment: https://git.openjdk.org/jfx/pull/1555#issuecomment-2344259476
