RFR: 8090456: Focus Management

[Andy Goryachev]

On Wed, 11 Sep 2024 17:18:58 GMT, Michael Strauß <mstrauss at 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