On Mon, 28 Oct 2024 23:20:49 GMT, Andy Goryachev <ango...@openjdk.org> wrote:

>>> If this flag is suddenly so important, then why doesn't `requestFocus` have 
>>> it?
>> 
>> That's easy: because we didn't deem it necessary. Back when we added the 
>> flag, only internal code would be able to set it, and that has worked out 
>> fine. Focus traversal using keyboard navigation didn't use `requestFocus()`.
>> 
>> Now we have a public API, and we face the same question again. There is a 
>> clear advantage of setting the focusVisible flag as a parameter of 
>> `requestFocusTraversal`: we ensure consistency between `focused` and 
>> `focusVisible`, such that a node cannot be focusVisible if not focused. 
>> Having focusVisible be a writable property would allow applications to have 
>> a node visibly indicate focus, or even multiple independent nodes indicating 
>> visible focus simultaneously, while yet another node is actually focused. 
>> That's not good.
>
> Perhaps we need to further clarify what the focused/focusVisible/focusWithin 
> properties are for?

How about this for `focusVisible`:

    /**
     * Indicates whether this {@code Node} should visibly indicate focus.
     * <p>
     * This flag is set when the node is {@link #focusedProperty() focused} via 
keyboard navigation,
     * or when the input focus was programmatically moved from another node to 
this node with
     * {@link #requestFocusTraversal} while the other node visibly indicated 
focus.
     * <p>
     * The {@code focusVisible} flag can be used by applications that do not 
want a permanent focus
     * indicator, and opt for a focus indicator that is only visible when it is 
most helpful to the
     * user. This is not the case when the user clicks on a control (because 
they would know which
     * control they clicked on), but only when a keyboard-initiated focus 
traversal moves the input
     * focus to another control.
     */


As `requestFocusTraversal` is concerned, I think we can simply this a bit. We 
don't need users to check whether `focusVisible` is set on the current node; 
the implementation can do this internally. Here's a revised parameter doc:

* @param keyNavigation {@code true} if this method is called as a result of 
keyboard navigation;
*                      {@code false} otherwise.


The implementation would then set `focusVisible` to true if either the 
`keyNavigation` argument is true, or if the current node's `focusVisible` flag 
is true.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1604#discussion_r1819905489

Reply via email to