<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: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;}
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="#0563C1" vlink="#954F72" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16"">Dear Michael:<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 don’t understand. In the past month and a half, we identified a number of problems, and are converging at a solution. Do you want to restart the process? Is there a special
order of doing things you would rather see?<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>
<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 Michael Strauß <michaelstrau2@gmail.com><br>
<b>Date: </b>Monday, November 20, 2023 at 14:06<br>
<b>To: </b><br>
<b>Cc: </b>openjfx-dev@openjdk.org <openjfx-dev@openjdk.org><br>
<b>Subject: </b>Re: Public Behavior API proposal<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">Hi Andy!<br>
<br>
I think this can be a valid approch, but I have concerns regarding the<br>
order in which we do things here.<br>
<br>
In my opinion, InputMap is a special case of a more general Behavior<br>
API. We should decide whether we want to revamp the control<br>
architecture at all, and if we do, then we should do the large-scale<br>
engineering first. Any control architecture proposal that has been put<br>
forth so far will not survive the rigorous follow-up engineering<br>
effort unscathed. Doing that first will undoubtedly inform the<br>
specifics of a potential InputMap API. If this was a minor feature, we<br>
could do it right now. But compared to other recent feature additions,<br>
this one has a very large surface.<br>
<br>
In an earlier email, you commented that maybe there wasn't enough<br>
engineering capacity at hand to do big things. But I think the<br>
discussions and preliminary work around Controls and Behaviors show<br>
that people are, in fact, willing and committed to investing a lot of<br>
effort to contribute to this project. So I would advocate to start by<br>
thinking big, and seeing where we end up.<br>
<br>
<br>
On Mon, Nov 20, 2023 at 9:16 PM Andy Goryachev<br>
<andy.goryachev@oracle.com> wrote:<br>
><br>
> Dear colleagues:<br>
><br>
><br>
><br>
> I wanted to gauge your opinion on a slightly different approach that addresses both John’s stateless behaviors use case as well as make it unnecessary to change existing event handling APIs but still enforce the right order of event handler execution.<br>
><br>
><br>
><br>
> Let’s call it a Split Input Map (more details later).<br>
><br>
><br>
><br>
> Control gets an InputMap property which stores the user event handlers and the user key bindings.<br>
><br>
><br>
><br>
> Skin has a SkinInputMap, a similar construct, which stores the event handlers and the key bindings registered by the behavior. The SkinInputMap comes in two flavors: one for the stateless behavior use case, and one for stateful behavior use case. In either
case the skin input map is set via Skin.setSkinInputMap() (a placeholder name, can be changed).<br>
><br>
><br>
><br>
> The difference between the two is the signature of the “function” mapped to a FunctionTag: the stateless requires Consumer<C extends Control>, and a stateful accepts a simple Runnable.<br>
><br>
><br>
><br>
> Furthermore, the event handling priority can be encapsulated within the input maps. For example, any event handler registered via either InputMap or SkinInputMap is guaranteed to be called according to its priority. For example, we could have five levels
(listed in the order of precedence):<br>
><br>
><br>
><br>
> USER_HIGH<br>
><br>
> SKIN_HIGH<br>
><br>
> USER_MID<br>
><br>
> SKIN_LOW<br>
><br>
> USER_LOW<br>
><br>
><br>
><br>
> Basically, event handlers added to the control’s InputMap can have { USER_HIGH, USER_MID, USER_LOW } priority, and those added to SkinInputMap can have { SKIN_HIGH, SKIN_LOW }. This makes it unnecessary to change the existing event handling APIs but solves
the issue with undetermined order of event handlers execution that we currently have in Controls.<br>
><br>
><br>
><br>
><br>
><br>
> Comment:<br>
><br>
> SkinInputMap is basically an equivalent of BehaviorContext in John’s proposal, and priority levels are unambiguous extension of Michael’s EventHandlerPriority.<br>
><br>
><br>
><br>
> What do you think?<br>
><br>
><br>
><br>
> -andy<o:p></o:p></span></p>
</div>
</div>
</div>
</div>
</body>
</html>