On Fri, 11 Jul 2025 10:14:03 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. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1632#discussion_r2201216087
