> On Feb 6, 2025, at 11:52 PM, Michael Strauß <michaelstr...@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.
