On Tue, 29 Oct 2024 16:07:17 GMT, John Hendrikx <jhendr...@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
