<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: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;}
.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"">Thank you for the feedback and suggestions!<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 think adding these methods to Node is not right, for the reasons explained in the JEP (as it effects changes outside of the said 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"">Also, there seems to be little utility in creating the directionality enum - the only reason to do so would, in my opinion, be within the context of a traversal policy, something
that appeared to be very controversial. I can't but notice how the example you gave tries to solve the same problem the traversal policy would solve.<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"">Thanks,<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>
<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ß <michaelstrau2@gmail.com><br>
<b>Date: </b>Monday, October 21, 2024 at 10:13<br>
<b>To: </b><br>
<b>Cc: </b>openjfx-dev@openjdk.org <openjfx-dev@openjdk.org><br>
<b>Subject: </b>Re: Proposal: Focus Traversal API<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">I think it is a good idea to do the non-controversial part of this<br>
feature first.<br>
<br>
With regards to the API, I would prefer a single instance method on Node:<br>
<br>
Node moveFocus(FocusTraversalKind);<br>
<br>
Where FocusTraversalKind is an enum with values UP, DOWN, LEFT, RIGHT,<br>
NEXT, and PREVIOUS.<br>
Note that it is not called "TraversalDirection", because NEXT and<br>
PREVIOUS are logical types of navigation, not directional ones.<br>
The return value is the node that will receive focus as a result of<br>
this method call.<br>
<br>
The name "moveFocus" pairs with "requestFocus" (and we could also<br>
potentially add "predictFocus" to get the node that would receive<br>
focus, without actully changing focus).<br>
<br>
Having a single instance method allows for easier composition, as I<br>
can now pass the FocusTraversalKind to methods, which is a bit awkward<br>
to do with method references.<br>
<br>
For example, I could write a method:<br>
<br>
/*<br>
* Moves the focus if allowed.<br>
* Returns true if the focus changed, false otherwise<br>
*/<br>
boolean moveFocusIfAllowedByBusinessLogic(Node node,<br>
FocusTraversalKind kind) {<br>
return switch (kind) {<br>
case UP, DOWN -> false;<br>
default -> isAllowed() && node.moveFocus(kind) != node;<br>
};<br>
}<br>
<br>
If I would instead pass a method reference to<br>
FocusTraversal::traverseNext into my custom method, I'm very limited<br>
in what I can do with it.<br>
For example, I can't switch() on the method reference, I can't change<br>
it with custom logic, etc.<br>
<br>
<br>
On Fri, Oct 18, 2024 at 10:25</span><span style="font-size:11.0pt;font-family:"Arial",sans-serif"> </span><span style="font-size:11.0pt">PM Andy Goryachev<br>
<andy.goryachev@oracle.com> wrote:<br>
><br>
> Dear fellow developers:<br>
><br>
><br>
><br>
> Thank you for providing a lively discussion here in the mailing list, and in the PR.<br>
><br>
><br>
><br>
> A surprisingly large number of objection was voiced, among them in no particular order (please correct me if I missed anything):<br>
><br>
><br>
><br>
> - no need for the traversal policy API, developers have all the tools they need<br>
><br>
> - rather than providing Parent.traversalPolicy, the whole thing should be delegated to Scene<br>
><br>
> - no need for custom traversal policies, provide a number of standard policies (e.g. cyclic/logical; or via enum if possible)<br>
><br>
> - introducing a new category of traversal events (later deemed unnecessary)<br>
><br>
> - adding two properties to Parent for directional and logical traversal<br>
><br>
> - desire to be able to configure traversal policy via CSS<br>
><br>
> - focus traversal methods should be instance methods in the Node class<br>
><br>
><br>
><br>
> Also, the discussion reiterated some of the design problems we have in JavaFX, namely<br>
><br>
><br>
><br>
> - controls consuming key events that effect no change in the control's state<br>
><br>
> - interference between controls' key handling and Scene's accelerators<br>
><br>
> - undetermined priority of event handlers registered by the skin and the application<br>
><br>
><br>
><br>
> I still believe there is a value in providing the traversal policy APIs, but given the general sentiment in the feedback, I think the right approach would be to scale down the proposal to leave only the focus traversal API [0], addressing a single use case
of the custom components [1].<br>
><br>
><br>
><br>
> I am sad to think that there will be no support for custom traversal policies in JavaFX in the foreseeable future, as it seems highly unlikely that my company will sponsor a major redesign of the focus subsystem. I hope there is a non-zero chance of the
open source community coming together and designing an alternative that satisfies everyone, so maybe not all is lost.<br>
><br>
><br>
><br>
> Please let me know what you think of the new proposal.<br>
><br>
><br>
><br>
> Thanks,<br>
><br>
> -andy<br>
><br>
><br>
><br>
><br>
><br>
> [0] </span><a href="https://github.com/andy-goryachev-oracle/Test/blob/main/doc/FocusTraversal/FocusTraversal-v2.md"><span style="font-size:11.0pt">https://github.com/andy-goryachev-oracle/Test/blob/main/doc/FocusTraversal/FocusTraversal-v2.md</span></a><span style="font-size:11.0pt"><br>
><br>
> [1] JDK-8091673 Public focus traversal API for use in custom controls<br>
><br>
> [2] Draft PR </span><a href="https://github.com/openjdk/jfx/pull/1604"><span style="font-size:11.0pt">https://github.com/openjdk/jfx/pull/1604</span></a><span style="font-size:11.0pt"><o:p></o:p></span></p>
</div>
</div>
</div>
</div>
</div>
</body>
</html>