<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:"Yu Gothic";
panose-1:2 11 4 0 0 0 0 0 0 0;}
@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;}
@font-face
{font-family:"\@Yu Gothic";
panose-1:2 11 4 0 0 0 0 0 0 0;}
/* Style Definitions */
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.apple-converted-space
{mso-style-name:apple-converted-space;}
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;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style>
</head>
<body lang="EN-US" link="blue" vlink="purple" style="word-wrap:break-word;line-break:after-white-space">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16"">Martin:<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"">I guess I am trying to say that I find the focus delegation idea as unnecessary - it feels to me like a band-aid on a broken event dispatching system. It might be the case
that the current design was there from the beginning, and so probably all the other issues we have encountered so far due to that design:<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 order of events is undefined<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16"">- the events are copied willy nilly and their isConsumed flag is ignored<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16"">- a parallel isConsumed mechanism gets invented<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16"">- it is possible for the application to create a misbehaving event dispatcher<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16"">- events that are intended for an inner component bubble up to the scene graph unnecessarily<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16"">- consumed events continue being dispatched<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16"">- multiple controls show input focus and handle input events simultaneously<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"">I am trying to find an alternative that will be easy for everyone to understand and use. Does not mean we should drop everything and re-write the whole thing, but I do want
to continue the conversation.<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"">-andy<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""><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""><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>
<div id="mail-editor-reference-message-container">
<div>
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal" style="margin-bottom:12.0pt"><b><span style="font-size:12.0pt;color:black">From:
</span></b><span style="font-size:12.0pt;color:black">Martin Fox <martinfox656@gmail.com><br>
<b>Date: </b>Friday, December 13, 2024 at 08:03<br>
<b>To: </b>Andy Goryachev <andy.goryachev@oracle.com><br>
<b>Cc: </b>OpenJFX <openjfx-dev@openjdk.org><br>
<b>Subject: </b>Re: [External] : Re: Focus delegation API<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt">Hi Andy,<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt">I’m trying to understand the use case you’ve outlined here since it doesn’t correspond to anything currently in JavaFX.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt"><br>
<br>
<o:p></o:p></span></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal"><span style="font-size:12.0pt">On Dec 10, 2024, at 8:32</span><span style="font-size:12.0pt;font-family:"Arial",sans-serif"> </span><span style="font-size:12.0pt">AM, Andy Goryachev <andy.goryachev@oracle.com> wrote:<o:p></o:p></span></p>
</div>
</blockquote>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt"><o:p> </o:p></span></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16"">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?</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16""> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16"">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?</span><o:p></o:p></p>
</div>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt"><o:p> </o:p></span></p>
</div>
<p class="MsoNormal"><span style="font-size:12.0pt">Are you proposing a control which delegates events to one inner node that changes over time OR a control which delegates a single key event to multiple inner nodes at once? If the latter, would all of those
inner nodes have the focused flag set?<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt">Neither of these correspond to a control design I’m familiar with. Can you point to an example? I can’t picture how such a control would appear to the user.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt">In either case would the delegate nodes be accessible via an API like a Spinner’s editor or hidden like a Spinner’s buttons? In the unlikely event that we wanted to deliver key events to a Spinner’s buttons
I could imagine using an internal mechanism but that doesn’t make much sense for the publicly accessible editor. Perhaps in your use-case we need two separate mechanisms for delivering key events, this PR and a different one for delegate nodes that aren’t
advertised via the control’s API.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt">Martin<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt"><o:p> </o:p></span></p>
</div>
<div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16""> </span><o:p></o:p></p>
</div>
<div id="mail-editor-reference-message-container">
<div>
<div>
<div style="border:none;border-top:solid windowtext 1.0pt;padding:3.0pt 0in 0in 0in;border-color:currentcolor currentcolor">
<p class="MsoNormal" style="margin-bottom:12.0pt"><b><span style="font-size:12.0pt">From:<span class="apple-converted-space"> </span></span></b><span style="font-size:12.0pt">openjfx-dev <<a href="mailto:openjfx-dev-retn@openjdk.org">openjfx-dev-retn@openjdk.org</a>>
on behalf of Michael Strauß <<a href="mailto:michaelstrau2@gmail.com">michaelstrau2@gmail.com</a>><br>
<b>Date:<span class="apple-converted-space"> </span></b>Monday, December 9, 2024 at 18:17<br>
<b>To:<span class="apple-converted-space"> </span></b><br>
<b>Cc:<span class="apple-converted-space"> </span></b>openjfx-dev <openjfx-dev@openjdk.org><br>
<b>Subject:<span class="apple-converted-space"> </span></b>Re: [External] : Re: Focus delegation API</span><o:p></o:p></p>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">> Yep, this seems unnecessary and counterproductive to me. All we need is to drop the target field from the event.<br>
<br>
I can't image that we would ever do this, considering that events have<br>
been there almost from the beginning. We'd break half of the JavaFX<br>
world if we changed the API of events.<br>
In addition to that, this would remove functionality. As of now, you<br>
can add a listener to Scene, and inspect which node is being targeted<br>
by an event.<br>
<br>
<br>
> > 2. ComboBox's skin has installed an event filter on ComboBox<br>
><br>
> So we have another scenario where different priorities are needed: adding event filters.<br>
<br>
Maybe, but that's a different problem than what's being solved by<br>
focus delegation. Focus delegation is all about removing defective<br>
ad-hoc implementations, and offering a pre-made building block for<br>
composite controls.<br>
<br>
<br>
> > 3. However, it must forward the event to the TextField (as otherwise<br>
> the TextField doesn't work), so it fires off a copy of the event<br>
> targeted at TextField.<br>
><br>
> 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.<br>
<br>
Sure, that would be an option. But it's not my preferred solution for<br>
the following reasons:<br>
1. It's gratuitously different. Instead of using events like they<br>
normally work, control skins would punch a hole through the scene<br>
graph, and deliver the event directly to the delegation target. That<br>
means that the skin's scene graph works differently as the outside<br>
scene graph, as you can't observe events traveling through it.<br>
2. It requires the skin to implement a complex protocol (register an<br>
event handler, copy the event, punch a hole through to the delegation<br>
target, send off the event), whereas the focus delegation proposal<br>
requires no additional implementation inside of the skin (aside from<br>
selecting the delegation target).<br>
<br>
The advantage of focus delegation is that it just works, even<br>
recursively, across arbitrary levels of abstractions (a skin might<br>
contain another control, which itself has a skin, and so on). No<br>
matter where you listen to events, you will always see exactly what<br>
you'd expect to see: an event that is targeted at the next focused<br>
node. This is another aspect of focus delegation, unrelated to events:<br>
it formalizes the notion of multi-level focus without resorting to<br>
hacks (like FakeFocusTextField). You'll need to solve this no matter<br>
what, as users can click on the TextField. As we discussed, the<br>
ComboBox must be the focus owner even when a user clicks on the<br>
TextField.<br>
<br>
<br>
<br>
> 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.<br>
<br>
First of all, it's only one property (Node.hoistFocus), not a bunch.<br>
And this is not related to events at all, it is a way for skins to<br>
indicate that clicking on an internal node will focus the outside<br>
control.<br>
<br>
The part of focus delegation that fixes the delivery of events in a<br>
scene graph with potentially nested abstractions is done without any<br>
new properties.</span><o:p></o:p></p>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<p class="MsoNormal"><span style="font-size:12.0pt"><o:p> </o:p></span></p>
</div>
</div>
</div>
</div>
</body>
</html>