RFR: 8091673: Public focus traversal API for use in custom controls [v3]

[Andy Goryachev]

On Tue, 29 Oct 2024 17:46:48 GMT, Michael Strauß <mstrauss at openjdk.org> wrote:

>>> What happens when a different type of event is created by a `KeyEvent` handler? How does the downstream code differentiate between the secondary events coming from a key event handler vs. from one originated normally?
>> 
>> This wouldn't matter IMHO, if you fire another event, that just deepens the call stack (the secondary event is fired immediately, not after the key event finishes); the original key event will still be the one that initiated it -- ie. user pressed a key, and focus changed as a result -- no matter how that exactly happened it is then FX's decision to turn on focus visible highlighting.  The whole focus visible highlighting is a feature provided by FX to give it a more native look and feel, but it may be platform dependent which is why I think the user should probably not have a say in the matter. 
>> 
>> I already suggested to make the property writable, but if the user can't be trusted to use it correctly, then they can't be trusted to set such a boolean correctly either.
>
> Is there really no conceivable scenario in which this method could legitimately be called _not_ in response to a key event, or is it simply that we're not thinking of such a scenario right now? I'd be bothered by an API that was created with a too-narrow focus in mind, and as a result doesn't allow me to do what I need.

Could you think of a scenario when we want a component focused but not indicate its focused state?

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

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