On Mon, 14 Jul 2025 18:46:53 GMT, Martin Fox <m...@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
