On Tue, 29 Oct 2024 17:46:48 GMT, Michael Strauß <mstra...@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
