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

[Michael Strauß]

On Tue, 29 Oct 2024 16:07:17 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> That seems reasonable, given that it is the expected use case. I wouldn't say "_must_ be called", but rather that it "is _expected_ to be called" in response to a KeyEvent, and then document the behavior accordingly -- namely, the node that receives focus will be `focusVisible`.
>> 
>> @mstr2 What do you think?
>
>> 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.

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

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