RFR: 8343956: Focus delegation API

John Hendrikx jhendrikx at openjdk.org
Mon Jul 14 19:02:45 UTC 2025


On Mon, 14 Jul 2025 18:46:53 GMT, Martin Fox <mfox at openjdk.org> wrote:

>>> > Does `resolveFocusDelegate` do what you need?
>>> 
>>> Currently we turn on input method processing at the platform level if and only if there's any control in the focus chain that is set up to receive input method events and respond to input method requests. That could be any focusOwner in any focused Scene or any one of the focusOwners' delegates. So I need to see the entire delegate chain.
>> 
>> Alright, so a method to get the current delegate would really help there, and I think that information should be available easily enough.
>> 
>>> If we don't expect the focus delegate to change while a focus scope node has focus then all I need is getFocusDelegate with no parameters. If we expect the focus delegate to change dynamically it should become a property.
>> 
>> I think the variant with a parameter has a different intent, and so I think we should not attempt to combine the two.
>> 
>>> > For example, for keyboard traversal, I don't see why this wouldn't work with multiple delegates (as its similar to having a Skin that has multiple focusable controls)?
>>> 
>>> The existing traversal machinery is designed to update a Scene's focusOwner not which delegate is active within the current focusOwner.
>>> 
>>> In the Date/Time control you give as an example how would the user move focus between the various delegates? What would be the most intuitive model for the user? Personally I prefer the one used in macOS Calendar where Tab is used to move between the month, day, and year (or hour and minute). But that creates a conflict with using Tab to move focus into and out of the Date/Time control as a whole.
>> 
>> Tab would definitely be the most intuitive model, and that's also what I would expect (and how this has worked for such controls since ages past).  So what I think is missing here is that in order to do correct navigation, Scene must be able to query the delegate of its current focus owner.  I think this could be done transparently:
>> 
>> - This PR already directs events to the current delegate, including events that are interpreted as navigation events
>> - Events targeted at a delegate already bubble up in the usual way, eventually reaching Scene
>> - Scene, when it wants to act on such an event for navigation, can ask its current focus owner to find out the actual control that received the event (the delegate).  This could be a parameterless `getFocusDelegate` or some such or a property.
>> - Scene then initiates the navigation logic from the delegate node (let's ...
>
> Yeah, I'm sure traversal is solvable, I just wanted to spend some cycles figuring it out. For example, would you set focusTraversable on the date/time control AND it's delegates? My guess is just the delegates but this is the sort of thing one would want to prototype.
> 
> To be clear I'm not trying to solve traversal in this round. I just want to make sure we have mapped out the path forward so the API will accommodate traversal eventually.

When I have a few moments, I'll see if I can create the date entry control, and see how it works with this solution.  I can then override Scene code to see if navigation is a quick fix or a huge issue.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1632#discussion_r2205607111


More information about the openjfx-dev mailing list