<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=Windows-1252">
<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: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;}
/* 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.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">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16"">I think I narrowed down my objection to this proposal. My main problem with it is that it tries to add properties to the wrong entity (Node).<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"">In a typical application, the focus traversal requirements usually come in the context of a higher level aggregate such as a form, or a panel, or a window, and not the individual
nodes. An example from Swing and AWT is the FocusTraversalPolicy class. This is no accident - the focus traversal might be dynamically dependent on other aspects of the UI state, for example the kind of information already present in a form.<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"">Trying to implement it at the Node level would be extremely difficult, and one will inevitably resolve to creating a kind of controller that determines the traversal order
at the higher level.<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"">A better approach, in my opinion, would be to revive the FocusTraversalPolicy API [0], [1] (after some modernization). The most important feature that would be added is enabling
ability to plug in a custom traversal policy that can address any application-level requirements with relative ease.<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"">What do you think?<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"">References<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"">[0]
<a href="https://github.com/andy-goryachev-oracle/Test/blob/main/doc/FocusTraversal/FocusTraversal.md">
https://github.com/andy-goryachev-oracle/Test/blob/main/doc/FocusTraversal/FocusTraversal.md</a><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"">[1]
<a href="https://github.com/openjdk/jfx/pull/1555">https://github.com/openjdk/jfx/pull/1555</a><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">openjfx-dev <openjfx-dev-retn@openjdk.org> on behalf of Michael Strauß <mstrauss@openjdk.org><br>
<b>Date: </b>Wednesday, July 16, 2025 at 23:33<br>
<b>To: </b>openjfx-dev@openjdk.org <openjfx-dev@openjdk.org><br>
<b>Subject: </b>Re: RFR: 8343956: Focus delegation API [v3]<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">On Mon, 14 Jul 2025 18:36:48 GMT, Martin Fox <mfox@openjdk.org> wrote:<br>
<br>
> In this PR setting hoistFocus on a control only updates the flag in the control itself. What if the control’s skin introduces sub-nodes? I would assume that setting hoistFocus on a control would automatically set that flag on the control’s entire skin. Is
that correct? If so what are the mechanics of making that happen?<br>
<br>
The `hoistFocus` flag only applies to the node on which it is set, and not to its descendants. Consider a control that uses a sub-control in its skin. If the sub-control also delegates focus to one of its own descendants, then those descendants individually
get to decide whether to hoist focus to the sub-control; and if so, the sub-control will further hoist focus to the outer control.<br>
<br>
Automatically setting this flag precludes the option to have sub-nodes that _don't_ hoist focus. Consider a Button: it has an optional sub-node (`graphic`) that is independently focusable and doesn't hoist focus. A custom button could conceivably have both:
a delegate (maybe a text field), as well as an independently focusable sub-node.<br>
<br>
> It seems hoistFocus is serving two roles. One is an optimization so that requestFocus knows whether it should walk the scene graph looking for a focus-scope node. For that use the flag should be propagated through descendants in the graph. But it’s also being
proposed as a hoisting barrier e.g. when it’s _not_ set it prevents focus from hoisting upward even if there's a focus-scope node higher up in the graph. But a barrier applies just to a single node and should not be propagated. So I’m having a difficult time
figuring out when and how this flag should be propagated through the tree. But I’m no expert on skins so maybe I’m assuming this is more complicated than it actually is.<br>
<br>
`hoistFocus` is not an optimization, it's semantically relevant in the way I described.<br>
<br>
-------------<br>
<br>
PR Review Comment: <a href="https://git.openjdk.org/jfx/pull/1632#discussion_r2212398078">
https://git.openjdk.org/jfx/pull/1632#discussion_r2212398078</a><o:p></o:p></span></p>
</div>
</div>
</div>
</div>
</div>
</body>
</html>