<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:Calibri;
        panose-1:2 15 5 2 2 2 4 3 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:"Calibri",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"">Dear John:<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"">Thank you for providing the alternative proposal.  One thing I liked is the clarification of the purpose of behavior to translate input events into platform-independent actions.<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 noticed you tried to validate the design using Button - a rather simple Control.  I think a better choice would be to pick one of the more complex controls such as TableView
 or TextArea.<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"">Another missing piece is probably a set of behavior tests similar to
<a href="https://bugs.openjdk.org/browse/JDK-8314906">https://bugs.openjdk.org/browse/JDK-8314906</a> to verify that the behavior does not change from the user perspective.<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"">One important problem I tried to solve is managing the key bindings.  I think it’s an important functionality that needs to be provided, evident from the plethora of use cases
 described earlier in the discussion.  I cannot see from the PR how you propose to address the issue, and the examples you mentioned earlier look to me more complicated than necessary.<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 have hard time understanding where the idea of static or singleton behavior comes from exactly, and what benefits it provides.  The whole design overlooks the fact that behaviors
 are tightly coupled to skins - to the point where it gets progressively difficult to provide a reasonable skin-to-behavior interface when skins have a different design (in appearance and the kinds and number of nodes involved).<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"">Adding more events and have them bubble up the hierarchy is, in my opinion, a departure from the current design, possibly a source of regression, impacts performance (however
 slightly), and is completely unnecessary.  The application developer can easily achieve that with existing mechanisms should such a function is indeed needed.<br>
<br>
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16"">Of course, I can be missing some important points altogether, and/or be completely wrong about
<i>what people want (tm)</i>.<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"">Now that Kevin is back from vacation, we could have an internal discussion of the two proposals to determine how we can move forward.<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 again for a lively discussion and the PR.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16"">Cheers,<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>
<div id="mail-editor-reference-message-container">
<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 John Hendrikx <john.hendrikx@gmail.com><br>
<b>Date: </b>Friday, October 20, 2023 at 14:40<br>
<b>To: </b>openjfx-dev@openjdk.org <openjfx-dev@openjdk.org><br>
<b>Subject: </b>Proof of concept pull request for Behavior API (PR 1265)<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="font-size:11.0pt">Hi list,<br>
<br>
I've made a proof of concept for possibly exposing Behaviors as a first <br>
class API in JavaFX.  It's by no means complete, and there will be some <br>
significant hurdles still no doubt, but this proof of concept does <br>
replace the internal ButtonBehavior completely with a newly implemented <br>
public ButtonBehavior (and it seems to be all working still).<br>
<br>
The proof of concept shows the basics behind this proposal, and <br>
introduces a Behavior interface, a BehaviorContext interface, a public <br>
ButtonBehavior and a class with ButtonEvents.<br>
<br>
There is also an Alternate ButtonBehavior which (somewhat clumsily) <br>
changes the SPACE key for selecting a button to the "A" key.  I suspect <br>
it shouldn't be too hard to make this a bit more streamlined.<br>
<br>
One thing of note that I haven't quite figured out yet; even though the <br>
new ButtonBehavior does not install the Navigation keys, Navigation <br>
still works; this is not because the old behavior is still active behind <br>
the scenes, but just seems to work out of the box.<br>
<br>
I'm hoping this will make the idea behind this proposal a bit easier to <br>
grasp.  Note that I'm also mainly trying to make it possible to be able <br>
to remap keys, but I want to make sure that this is done in such a way <br>
that it doesn't block a future open sourcing of a Behavior API.  With <br>
this proposal it's possible however that Behaviors must become public <br>
first though before being able to access the necessary classes to change <br>
input mappings.<br>
<br>
The PR can be found here: <a href="https://github.com/openjdk/jfx/pull/1265">https://github.com/openjdk/jfx/pull/1265</a><br>
<br>
Feel free to comment here or on the PR.  The PR is in draft, so comments <br>
there will not show up on the mailing list.<br>
<br>
Note: the test failure is because tests are using reflection to access a <br>
behavior field that is part of skins; this field is no longer present <br>
for ButtonSkin.<br>
<br>
--John<o:p></o:p></span></p>
</div>
</div>
</div>
</div>
</body>
</html>