On Mon, 28 Oct 2024 22:37:34 GMT, Andy Goryachev <ango...@openjdk.org> wrote:
>> If this flag is suddenly so important, then why doesn't `requestFocus` have >> it? >> >> I feel that we've found an internal inconsistency, and that the solution is >> to then drop this on the user to ensure correctness (the wording "callers >> must specify" definitely alludes to this). It's like asking users to pass >> along some important flag, and if they get it wrong the system breaks. >> >> I think the request focus call should take the most sensible value for >> focusVisible on programmatic changes, and that FX should not be using this >> API itself. Now we're just exposing focusVisible in a round-about way (as a >> boolean flag of some other call) to make it user controllable -- then why >> not just make it writable? If I don't like the calculated default (or >> perhaps always `true`), then I can call `Node#setFocusVisible(false)` after >> the request focus call. > > Good question, @hjohn . Why indeed, @mstr2 ? > 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. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1604#discussion_r1819882547
