<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 further development of this idea, especially defining the separation between Control, Skin, and Behavior.<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"">Do I read correctly that semantic events are currently off the table? Or, at least, either an implementation detail or some future enhancement?<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 also have a few comments in regards to the strict rules e.g. “C. never modifies its own publicly writable properties” and the reasoning behind those, but that deserves a
separate email.<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"">For now, I just want to note that BehaviorContext looks suspiciously like an InputMap (a skin/behavior InputMap), and the fact that you invent a State class indicates that,
at least in this example, we are dealing with a stateful behavior. In other words, why not have a BehaviorBase?<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"">So the only case where we might have a stateless behavior and thus save a few bytes by using a singleton key map is where the control either has no state, or the state is fully
encapsulated within control’s properties. I agree we should support those (rare?) cases should developers want it.<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 I am getting at here is that if we provide an InputMap and a SkinInputMap instead, then we can have the freedom to implement stateful and stateless behaviors as well as
provide key mapping functionality as well as the prioritization of event handlers (if registered via the input maps).<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""><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, November 24, 2023 at 18:21<br>
<b>To: </b>openjfx-dev@openjdk.org <openjfx-dev@openjdk.org>, Michael Strauß <michaelstrau2@gmail.com><br>
<b>Subject: </b>Looing for feedback: Behavior API Proposal V2<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 written down a new Behavior API proposal which has some interesting <br>
changes to even better separate behavior from skins.<br>
<br>
Skins currently already determine much of the behavior by only <br>
installing specific event handlers, or only calling behaviors in <br>
specific instances (they effectively are already doing some <br>
interpretation or filtering of events). This proposal aims to do away <br>
with all that, allowing behaviors to be in full control on what events <br>
they wish to listen to, even for events triggered on the skins children <br>
or substructure.<br>
<br>
An example is SpinnerSkin, which currently dictates without the behavior <br>
being able to intervene that ALL mouse buttons will trigger the spinner <br>
buttons (this is most likely a bug, but shows that skins have too much <br>
control here). The behavior once triggered lacks the necessary <br>
information to filter this to only the primary button as the event was <br>
already interpreted by the skin.<br>
<br>
This proposal changes this by letting all relevant substructure events <br>
bubble up to the control level, where the behavior is free to install <br>
any event listeners it wants to do anything it wants. All that is needed <br>
to make this work is a way for the behavior to know on which part of the <br>
substructure an event was triggered. This can be determined by examining <br>
the event target, and together with already public information about the <br>
skins substructure (available for CSS) this is enough to allow behaviors <br>
to respond to any possible event performed on a specific piece of <br>
substructure, and not just events sanctioned by the skin.<br>
<br>
This will make it possible for behaviors to be a really powerful API to <br>
radically alter how visuals react to mouse movements, keyboard events, <br>
drags, gestures, etc, without being limited by the skin designer's <br>
imagination. An example would be to have Spinners react to the scroll <br>
wheel, which currently is not possible without the skin's cooperation.<br>
<br>
This proposal leaves out the semantic event concept for now as something <br>
that can be added later. Since they're not needed anymore for skins to <br>
communicate with behaviors, they can wait a bit.<br>
<br>
The proposal also includes ways of dealing with Behaviors that require <br>
knowledge of the exact visual layout a skin provides (TextAreaBehavior) <br>
that I think is not an unsatisfactory solution.<br>
<br>
<a href="https://gist.github.com/hjohn/c7b1bf9d4a4770b1b3ae854b20fbaa94">https://gist.github.com/hjohn/c7b1bf9d4a4770b1b3ae854b20fbaa94</a><br>
<br>
Looking forward to hearing your feedback!<br>
<br>
--John<br>
<br>
<br>
<br>
<o:p></o:p></span></p>
</div>
</div>
</div>
</div>
</body>
</html>