[External] : Re: Focus delegation API

[Michael Strauß]

> 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. For example, consider a
Control that contains a sub-graph of nodes and, eventually, a
TextField. The idea is that the events received in the Control's
sub-graph should be consistent with what would happen if the sub-graph
was a top-level scene graph. What you could probably do in Control, is
sending the event directly to its delegation target. But that would
exclude listeners between the Control and its delegation target:
Control=>[other nodes]=>target.


> This PR also introduces a much cleaner way of getting the focused property set on the internal TextField of a ComboBox or Spinner. This seems to be the one part of the proposal that really needs to be in Node (and which would drag the stuff I already mentioned into Node). But it raises a question: why is JavaFX setting the focused property on the TextField editor to begin with? I presume it’s to ensure the editor has the correct visuals but this means two focus rings are shown when a ComboBox has focus.

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.

However, you point out an obvious sharp edge here. Consistent focus on
sub-graphs also drag CSS into the equation, and this is where it gets
a bit messy. The basic idea seems reasonable: JavaFX allows you to
create new controls simply by composing existing controls. But it's
not that easy: in some cases, you probably don't want nested focus
rings in your composite control. But maybe you want the inner
TextField to indicate focus in a different way, let's say with a
colored background?

Currently, styling composite controls is a bit awkward, since you'll
need to provide styles for the inner control that undo things you
don't need from the outer control. For exampe, if the outer control
specifies a blue focus ring border, you'll need a contextual style for
the inner control that makes the border go away. This entangles the
styling of the outer and inner control in a very cumbersome way.


> It also means that the editor’s focus ring shows up even if it’s not editable.

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.


> Finally, an observation. Currently someone can attach an event handler on a Scene and see all events targeted at TextFields including TextFields inside ComboBoxes and Spinners. With this PR that would no longer work and they would have to attach their filter directly to those internal TextFields. I don’t have a strong opinion on whether this is a good idea or not but it should probably be noted in the proposal.

Good point, I've added this to the proposal text.