On Sat, 12 Jul 2025 10:14:55 GMT, John Hendrikx <jhendr...@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. >> >> 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. >> >>> 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. >> >> In any case the question is whether a monolithic control with multiple >> delegates is expected to roll its own internal traversal mechanism or if we >> need to extend the existing mechanism to include delegates. Having each >> control roll its own internal traversal would hide it from the accessibility >> frameworks. And if we expect the existing traversal keys (like Tab) to work >> internally we should extend the existing traversal machinery to work with >> delegates. > >> > 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 say > it is in a field of a composed ... 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. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1632#discussion_r2205586668
