<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p><br>
</p>
<div class="moz-cite-prefix">On 06/12/2024 20:16, Andy Goryachev
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:BYAPR10MB3013E5DFC75F01E81C75D817E5312@BYAPR10MB3013.namprd10.prod.outlook.com">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<meta name="Generator"
content="Microsoft Word 15 (filtered medium)">
<style>@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}@font-face
{font-family:Aptos;
panose-1:2 11 0 4 2 2 2 2 2 4;}@font-face
{font-family:"Iosevka Fixed SS16";
panose-1:2 0 5 9 3 0 0 0 0 4;}@font-face
{font-family:"Times New Roman \(Body CS\)";
panose-1:2 11 6 4 2 2 2 2 2 4;}p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:10.0pt;
font-family:"Aptos",sans-serif;}a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Iosevka Fixed SS16";
color:windowtext;}.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;
mso-ligatures:none;}div.WordSection1
{page:WordSection1;}</style>
<div class="WordSection1">
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Iosevka Fixed SS16"">Returning
to this discussion.<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Iosevka Fixed SS16""><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Iosevka Fixed SS16"">Consider
the following scenario: a compound control such as ComboBox,
which has an editable TextField control as a part of its
skin. It might be expected that the ComboBox shows the
focused border instead of its TextField even when the latter
has the input focus.<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Iosevka Fixed SS16""><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Iosevka Fixed SS16"">When
the user presses and releases a key, the key events are
first dispatched to the input focus owner which is the
TextField. This part is correct.</span></p>
</div>
</blockquote>
No, this is incorrect. The focus owner is the ComboBox, not some
inner component of it, and so events are dispatched to the
ComboBox. The focused border is shown around the ComboBox, which is
exactly what is expected. As far as the user is concerned, ComboBox
is a fully implemented native control without substructure; to make
the implementation of such a control a bit easier (and less
repetitive), JavaFX has elected to allow Controls to have children
that can handle some of the tasks of a complicated control. These
children however are an implementation detail(as they must be as
Skins provide them, and they are not mandated to follow specifics.
It also would have been perfectly acceptable to have created a
ComboBox control that does not rely on any other controls and
replicates all TextField functionality natively.<br>
<blockquote type="cite"
cite="mid:BYAPR10MB3013E5DFC75F01E81C75D817E5312@BYAPR10MB3013.namprd10.prod.outlook.com">
<div class="WordSection1">
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Iosevka Fixed SS16""><o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Iosevka Fixed SS16""><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Iosevka Fixed SS16"">The
issue we seem to be struggling with is that, unlike the case
when TextField is used as a top level control, now it is a
part of a ComboBox. Which means it should not handle some
keys/events, instead delegating them to the top level
control - there should be a single "controller" (in MVC
parlance), instead of two fighting each other. This
statement applies to built-in controls as well as the custom
controls.</span></p>
</div>
</blockquote>
<p>I think you have this upside down.<br>
</p>
<p>The single controller is the ComboBox. Events arrive there
first. It encapsulates all its other functionality, including the
TextField (if there is one at all, perhaps it is all "custom"
drawn). The ComboBox, fully in control, can decide that it wants
some events handled by its children if that is convenient. This
is done by internally forwarding the event at a child (you can
even fire the event --directly-- at the child component, there is
no hierarchy requirement here).</p>
<p>The opposite is also true; all events an inner control may
generate will have to pass scrutiny by the ComboBox, or the
ComboBox is free to configure its children in such a way that they
won't generate events (ie. by capturing triggering events before
they reach the control, by replacing the event dispatcher or
setting event handlers directly).</p>
<p>Michael's proposal streamlines all of this, providing one solid
implementation as it is easy to make mistakes in the event
handling, or even use hacky work-arounds, like subclassing,
refiring events at new targets, fake focuses...<br>
</p>
<span
style="font-size:11.0pt;font-family:"Iosevka Fixed SS16""><o:p> </o:p></span>
<blockquote type="cite"
cite="mid:BYAPR10MB3013E5DFC75F01E81C75D817E5312@BYAPR10MB3013.namprd10.prod.outlook.com">
<div class="WordSection1">
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Iosevka Fixed SS16"">One
way to accomplish that is to register a bunch of event
<b>filters</b> with the top level control, to prevent the
events to arrive at the inner control, forwarding these
events to the top level controller, which in JavaFX case is
the behavior.<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Iosevka Fixed SS16""><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Iosevka Fixed SS16"">The
other way which I think will be easier, is to use the
proposed InputMap to remove the undesired mappings from the
inner control. Doing so does not involve subclassing of the
inner controls, since the input map and the mappings will be
a public API. With the mappings disabled (or remapped to
the functions provided by the top level control), there is
no contention between the two anymore. The top level
<i>control</i>'s <i>controller</i> is in full <i>control</i>,
it can do anything that's required to the inner controls -
setting pseudo styles, inserting text, etc. As an example -
the right arrow key in the combo box's text field can be
remapped to a function which checks if the caret is at the
last position and then move the focus to the button, if so
desired. And if the caret is not at the last position, the
default function of text area is invoked - all that enabled
by the InputMap.</span></p>
</div>
</blockquote>
<p>There is no subclassing needed in the focus delegation API
either; that's one of the hacks it will be removing. InputMap
does not need to be involved with this at all. I mean, you are
basically seeing exactly the intention (the top level control's
controller is in full control) but then involve the InputMaps
unnecessarily. InputMaps are just event handlers backed by a Key
to Action map. Adding focus concerns here is clearly overstepping
their bounds, not to mention they would have to support arbitrary
events.<br>
</p>
<p>--John<br>
</p>
<span style="font-size:11.0pt"><o:p></o:p></span>
</body>
</html>