[External] : Re: Focus delegation API

[Martin Fox]

> On Feb 6, 2025, at 11:52 PM, Michael Strauß <michaelstrau2 at gmail.com> wrote:
> 
>> This PR uses an event dispatcher to provide a cleaner way of channeling keyboard events to another node. I haven’t prototyped the code but I suspect a Control could do this using the existing API without any changes to the Node class.
>> This PR also provides an API to query a node’s delegate, finally making the delegation public. This could also be an aspect of a Control rather than a Node.
> 
> I'm not sure you could do that. The redirecting event dispatcher
> ensures that on each level of abstraction, you'll see events exactly
> how you would expect to see them in isolation.

I should have been clearer. In your PR the retargeting event dispatcher is added in Node.buildEventDispatchChain. I was thinking that it could be added in Control.buildEventDispatchChain. So I was playing devil’s advocate and suggesting that all of this get moved to Control. After all it seems like a lot of machinery to add to Node to clean up the implementation of a small number of controls.

But on re-reading the PR I see that it’s the child of the delegating node that’s adding the dispatcher. Could you elaborate on why that is? It looks like you’re trying to ensure that the re-targeting of the event happens after the Control is done processing it even if a Control subclass overrides buildEventDispatchChain.

I’m fine with adding focus delegation to Node instead of Control. In fact I would recommend it since it provides a clean way of getting InputMethod events working.

> That's another aspect of the "consistency story" that this proposal
> tries to tell: you should be able to reason about the sub-graph of a
> Control in the same way as you reason about a top-level graph. If your
> control receives input, then it should also be focused.

I should have asked a different question. Is the focused flag being set to ensure the focus ring shows up? Or is it being set for some other reason and the focus ring is an unwelcome side-effect?

I’m trying to get a handle on what parts of the system rely on this flag because the documentation is incorrect and the implementation is murky. For example, the ListView and TreeView manipulate the focused flag in surprising ways and it’s not entirely clear if this is just bookkeeping or if they’re also trying to invoke some specific behavior in another part of the system (like CSS).

> I think that a node that is disabled, not editable, or not focus
> traversable should probably not be eligible to be a focus delegate.
> That would be inconsistent with top-level graphs.

I don’t think a ComboBox’s editor should be focus traversable since the user should never be able to traverse to it.

I’m not sure how you would enforce these restrictions. The enabled state is a property of Node but the editable state is not.

This raises another question. Can the focus delegate of the focusOwner change dynamically? For example, what if the editor inside a ComboBox changes to an enabled state while the ComboBox is the focusOwner? I ask because the code that enables and disables InputMethod events queries state and needs to be aware of changes to that state. If we extend that state to include delegates (and I think we should) we need to know when a delegate might change.