[External] : Re: Focus delegation API

[Andy Goryachev]

Michael:

Please help me understand.

How does the idea of focus delegation works with multiple inner nodes that are supposed to handle different aspects of a complex control?  For example, a custom combo box-like control may contain an editor (possibly created dynamically), may be a couple of buttons, may be even two editors.  How would that work?

In this example, the buttons need focus to respond to ENTER or SPACE key presses, the editors should respond to key typed and maybe LEFT/RIGHT arrow keys to switch between the two, and so on.  Will the proposed design still work?

If we presume the model in which the control is a monolithic entity, then we must accept the fact that there is a separate mechanism for the top level control to manipulate its skin constituents.  How it is done is not that important - events, or direct method calls, not important.  Since we don't often have direct methods, using the events is probably the easiest.

My point is that the mechanism of isolating the parts of skin from the usual event handling is **necessary**, especially when it comes to bubbling of events up the hierarchy.  Adding a bunch of methods trying to simulate that seems to be less optimal and more complicated.

What do you think?

-andy


From: openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of Michael Strauß <michaelstrau2 at gmail.com>
Date: Monday, December 9, 2024 at 18:17
To:
Cc: openjfx-dev <openjfx-dev at openjdk.org>
Subject: Re: [External] : Re: Focus delegation API
> Yep, this seems unnecessary and counterproductive to me.  All we need is to drop the target field from the event.

I can't image that we would ever do this, considering that events have
been there almost from the beginning. We'd break half of the JavaFX
world if we changed the API of events.
In addition to that, this would remove functionality. As of now, you
can add a listener to Scene, and inspect which node is being targeted
by an event.


> > 2. ComboBox's skin has installed an event filter on ComboBox
>
> So we have another scenario where different priorities are needed: adding event filters.

Maybe, but that's a different problem than what's being solved by
focus delegation. Focus delegation is all about removing defective
ad-hoc implementations, and offering a pre-made building block for
composite controls.


> > 3. However, it must forward the event to the TextField (as otherwise
> the TextField doesn't work), so it fires off a copy of the event
> targeted at TextField.
>
> Maybe instead, there should be a way to send the event to a Node directly, without bubbling up.  These internal events should never propagate outside of the skin's internals.

Sure, that would be an option. But it's not my preferred solution for
the following reasons:
1. It's gratuitously different. Instead of using events like they
normally work, control skins would punch a hole through the scene
graph, and deliver the event directly to the delegation target. That
means that the skin's scene graph works differently as the outside
scene graph, as you can't observe events traveling through it.
2. It requires the skin to implement a complex protocol (register an
event handler, copy the event, punch a hole through to the delegation
target, send off the event), whereas the focus delegation proposal
requires no additional implementation inside of the skin (aside from
selecting the delegation target).

The advantage of focus delegation is that it just works, even
recursively, across arbitrary levels of abstractions (a skin might
contain another control, which itself has a skin, and so on). No
matter where you listen to events, you will always see exactly what
you'd expect to see: an event that is targeted at the next focused
node. This is another aspect of focus delegation, unrelated to events:
it formalizes the notion of multi-level focus without resorting to
hacks (like FakeFocusTextField). You'll need to solve this no matter
what, as users can click on the TextField. As we discussed, the
ComboBox must be the focus owner even when a user clicks on the
TextField.



> Well, we don't need to add a bunch of weird properties for that (the first part).  Just send the events to the skin's components directly, preventing the bubbling up part.  There is no need for Event.target because there is no extraneous events being bubbled up, and both CB and TF can process the events as they come in.

First of all, it's only one property (Node.hoistFocus), not a bunch.
And this is not related to events at all, it is a way for skins to
indicate that clicking on an internal node will focus the outside
control.

The part of focus delegation that fixes the delivery of events in a
scene graph with potentially nested abstractions is done without any
new properties.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20241210/155cd039/attachment-0001.htm>