On Tue, 29 Oct 2024 14:45:53 GMT, Andy Goryachev <ango...@openjdk.org> wrote:
>> I think it could be possible, but I'm not sure if it would be pretty. Scene >> is the one dispatching these events, and since FX has a single threaded >> model, Scene could have a flag that indicates it is currently dispatching a >> key event. If `requestFocusTraversal` is called, it can detect if this was >> in response to a key event higher up the call stack by checking the flag on >> Scene. >> >> I do think there are other mechanisms in FX that pass along information from >> shallower callstacks to deeper callstacks in some form or another. >> `ExpressionHelper` for example is aware of nested calls and takes action >> accordingly, and I'm almost certain there are more in places were FX is >> dealing with peers and syncing the scene graph. > > 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? > >> Is there enough information for the implementation of requestFocusTraversal >> to know whether it was called from keyboard event? > > The (original) intent of this API is to enable the custom components trigger > the focus traversal as a response to key events only, the problem is that we > can't prevent the application code from misusing the API and calling it for > other reason. (There is no other reason for the application code or custom > component to call this method with the `visible=false`, other than misuse) > > I would rather specify that this method must be called as a response to > KeyEvent, and drop the argument. 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? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1604#discussion_r1821019878
