On Fri, 3 Jan 2025 10:36:23 GMT, John Hendrikx <jhendr...@openjdk.org> wrote:
>> Implementation of [focus >> delegation](https://gist.github.com/mstr2/44d94f0bd5b5c030e26a47103063aa29). > > This looks really good. I'm wondering if this could be simplified further. > Specifically, I think the `hoistFocus` flag and manual management of the > focus delegate may not be needed. > > It seems to me that a Control could share some similarities with a Scene, in > that Control has properties that track a focus owner (similar to focus > delegate). In effect, a Control is a focus root similar to scene. When a > Scene receives focus, it determines the best Node to "delegate" focus to; > similarly, when a Control receives focus, it determines which skin control > should be focused. The normal focus rules should do the right thing here and > for example select the TextField of a Spinner as the delegate automatically > (some children may need to be marked as not focusable to guide the auto > selection, but this is an already existing standard mechanism). > > When determining where to send events, if the target is a focus root, it > queries its focus owner (or focus delegate) and extends the event to that > target. If that target is also a focus root, the process repeats. > > The request focus function should operate differently as well. It should > look for the closest focus root (a Control or Scene) and call the appropriate > request focus function on the root it finds. If that root is Scene, > everything works as usual. If it is another focus root like a Control, > Control can determine the best way to focus one of its child nodes (likely > you can just apply a normal search for an eligible focusable control for > this). > > Perhaps the focus root functionality can be captured in an interface that > both Scene and Control implement. I think it would need to specify a > `requestFocus` method and `focusOwnerProperty`. This interface would then > replace the `focusScope` flag. @hjohn I think what's missing in your model is the option to have an independently focusable node inside of a control. For example, think of a Button placed within a Button (via its `graphic` property). Clicking the nested button should not transfer the focus to its parent button. Whether a focus request should be hoisted is a choice that depends on the specifics of the control, and we probably need an API for that. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1632#issuecomment-2637581233
