<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:"Yu Gothic";
panose-1:2 11 4 0 0 0 0 0 0 0;}
@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;}
@font-face
{font-family:"\@Yu Gothic";
panose-1:2 11 4 0 0 0 0 0 0 0;}
@font-face
{font-family:"Iosevka Fixed SS16 ";
panose-1:2 0 5 9 3 0 0 0 0 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:10.0pt;
font-family:"Calibri",sans-serif;}
span.EmailStyle20
{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"">It is difficult to review the alternative proposal for a number of reasons. A prototype is a good start, but for any proposal to go forward we need a bit more work. Let me
enumerate the steps that we expect:<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. Provide an overview of the proposal following a JEP outline:<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"><b><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16"">Summary</span></b><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16""><o:p></o:p></span></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16"">Goals</span></b><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16""><o:p></o:p></span></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16"">Non-Goals</span></b><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16""><o:p></o:p></span></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16"">Motivation</span></b><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16""><o:p></o:p></span></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16"">Description</span></b><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16""><o:p></o:p></span></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16"">Alternatives</span></b><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16""><o:p></o:p></span></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16"">Risks and Assumptions</span></b><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16""><o:p></o:p></span></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16"">Dependencies</span></b><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"">2. A draft PR that provides a proof of concept, using, in this case, a few complex controls like TextArea, TableView, ComboBox.<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"">3. Address the question raised earlier, perhaps by providing code examples (pseudo code is acceptable, I 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"">More specifically, I’d like to know how the following concerns will be addressed by the new proposal:<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"">Q1. Changing an existing key binding from one key combination to another.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16"">Q2. Remapping an existing key binding to a different function.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16"">Q3. Unmapping an existing key binding.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16"">Q4. Adding a new key binding mapped to a new function.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16"">Q5. (Q1...Q4) scenarios, at run time.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16"">Q6. How the set behavior handles a change from the default skin to a custom skin with some visual elements that expects input removed, and some added.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16"">Q7. Once the key binding has been modified, is it possible to invoke the default functionality?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16"">Q8. How are the platform-specific key bindings created?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16"">Q9. How are the skin-specific (see Q6) handlers removed when changing the skins?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16"">Q10. When a key press happens, does it cause a linear search or a map lookup?
<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<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>
<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">John Hendrikx <john.hendrikx@gmail.com><br>
<b>Date: </b>Tuesday, October 24, 2023 at 04:58<br>
<b>To: </b>Andy Goryachev <andy.goryachev@oracle.com>, openjfx-dev@openjdk.org <openjfx-dev@openjdk.org><br>
<b>Subject: </b>Re: [External] : Re: Proof of concept pull request for Behavior API (PR 1265)<o:p></o:p></span></p>
</div>
<p><o:p> </o:p></p>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">On 23/10/2023 23:57, Andy Goryachev wrote:<o:p></o:p></span></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16 ""> </span><span style="font-size:11.0pt">
<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:.5in">You'd create a new class, `MyBehavior`,<o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16 ""> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16 "">By “customizing” I also mean at run time. Creating new classes wouldn’t work.
</span><o:p></o:p></p>
</blockquote>
<p>This would also work at runtime, as the class you create can <span style="background:yellow;mso-highlight:yellow">
be instantiated with parameters that control its key binding behavior</span>. Even though the standard Behaviors should probably be singletons (so they can be reused and composed) or have public well documented constructors, a custom behavior created by the
user has no such re-usability restrictions.<o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16 ""> </span><o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in"><span style="background:yellow;mso-highlight:yellow">coupling</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16 ""> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16 "">I don’t think it is our choice - it is up to the skin designed. If they add a node that needs to take input, or if the behavior is drastically different, it is almost impossible
to create a common interface. So skin and behaviors are coupled, besides we have to design for the worst case (of a totally different skin). The division between S and B comes mostly from the division between V and C in MVC. From a distance, the user does
not see it at all - all they see is a control.</span><o:p></o:p></p>
</blockquote>
<p>JavaFX is not doing MVC.<o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt">In MVC, the 3 components are not entangled; Model refers View, Controller refers View and Model, View refers nothing; in JavaFX the View (Skin) creates the Controller (Behavior); the View especially normally
can be created without any dependencies, and can be tested as such; with Skins being tightly coupled to both Behaviors and Controls, that doesn't even come close.<o:p></o:p></span></p>
<p>For it to be MVC you'd need to:<o:p></o:p></p>
<p>- Remove reference from Skin to Control<br>
- Do not let Skins create Behaviors<br>
- Instantation order should be, create a Skin first (with no Control reference), then create the Control (with Skin as parameter or setter), then create a Behavior (with Control as parameter, and one or more Views (Skins))<o:p></o:p></p>
<p>What JavaFX is exactly, I don't know. It doesn't follow MVC (even though it claims to) because in the current setup the Skin is both V and C; that's not MVC. At most it is MS (Model Skin), and so there is no reason to expose anything beyond the Skin then,
as that would just be pretending to be something that it is not.<o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16 ""> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16 "">This suggest another metric at judging the usefulness of a design - how easy it is to understand and perform 80% of most common tasks.</span><o:p></o:p></p>
</blockquote>
<p class="MsoNormal"><span style="font-size:11.0pt">Now that I explained how key remappings would work, I don't see how this would disqualify the alternative proposal.<br>
<br>
<o:p></o:p></span></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16 ""> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16 "">There are more interesting ideas at the end of the message I am replying to - fxml, css, global changes - these go far beyond the simple input map improvement. I did mention
this already, but neither open source community, nor my employer might have the resources to make such drastic changes.</span><o:p></o:p></p>
</blockquote>
<p class="MsoNormal"><span style="font-size:11.0pt">I didn't mention FXML, but yes, I gave some other things to think about. As for how drastic any of those are, that remains to be seen. Certainly the global changes would not be that hard at all. The CSS
proposal would need some research if there is some will to go there; it assumes that the information needed can be transported in a reasonable manner to the key binding system using the existing CSS infrastructure.<br>
<br>
<o:p></o:p></span></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16 ""> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16 "">So we have to be realistic, I think. We are travelling to a different planet in a small spaceship and we only have so much material and oxygen to play with. A simple improvement
that helps 80% of use cases might be better than a major redesign (I still think the event proposal involves major redesign).</span><o:p></o:p></p>
</blockquote>
<p>I think that if that's the case that we'd better focus on making it possible for 3rd parties to deliver these features, and do the simplest thing that would allow them to do so. That would be prioritized event handlers (so a 3rd party can always intercept
before the Skin/Behavior gets to it) + a flag to skip system event handlers (ala consumed) to allow bubbling up.<o:p></o:p></p>
<p>On top of that any key remapping or behavior change system can be constructed already.<o:p></o:p></p>
<p>--John<o:p></o:p></p>
</div>
</div>
</div>
</body>
</html>