On Wed, 11 Sep 2024 17:18:58 GMT, Michael Strauß <mstra...@openjdk.org> wrote:
>> Thank you @mstr2 for a detailed writeup!
>>
>> I fully agree with you that the majority of use cases can be handled with
>> the existing policies.
>>
>> 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).
>>
>> 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.
>>
>> Another question is whether there exists a policy that cannot be implemented
>> by the new APIs provided by this PR.
>>
>> What do you think?
>
>> 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 p...
Thank you @mstr2 for your comments! Since we also have a parallel discussion
in the mailing list, I'll respond there.
I think we both agree that the main goal of this proposal (or any proposal) is
to make _the things_ easier in the most common scenarios, while making all
other scenarios possible. Right now it is simply not possible to do focus
traversal on the application side.
This proposal makes focus traversal and custom policies possible. You are
right that in most cases the default policy would be sufficient, and we also
might provide additional standard policies (like one based on an array of Nodes
within a Parent), and that should cover 99% of the use cases.
One thought I'd like to vocalize: the idea of setting traversal properties or
policies from CSS does not feel right to me. The CSS define presentation
aspects (styles) rather than behavioral ones. I know it is possible to set
custom skins and the corresponding behavior via CSS, and we know why (skins
define the appearance), but we should not go beyond that, in my opinion.
-------------
PR Comment: https://git.openjdk.org/jfx/pull/1555#issuecomment-2350160842
