<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;}
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 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"">Thank you for a thoughtful feedback!<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"">You are correct - the new proposal is a variation of the old one, with modifications intended to address the earlier use cases identified by you and John, namely the event
handler priority and the stateless behaviors.<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"">The reason I propose to solve the even priority issue in the Control and its InputMap is simply because I think this is the only place where we have multiple actors shuffling
the event handlers: we have the application initial configuration, we have the old skin, possibly the new skin that replaces the old one, and we might have user settings being restored at run time. I thought the new design addresses these use cases nicely,
but it looks like you believe there are use cases that require explicit prioritization of event handlers for things other than Controls. Can you provide an example please?<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"">As for the second part (items 1-4), I suspect you might be still not considering a use case of user customization at run time or from settings. To give an example, in the
context of a text editor, the user may want to map Ctrl-D to a DELETE_PARAGRAPH function, or not, as a part of user-set key bindings (or map some other key combination). While I suppose it's possible to support this requirement by adding and removing a key
event handler (one per key?), the InputMap provides a uniform and a rather convenient API.<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"">Similarly, the application requirements might call for runtime unmapping of user bindings, in which case we want an easy API to undo the change and revert back to the default
functionality. Sure, we can juggle the event handlers, but again, the InputMap provides a nice API for that.<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"">Having said all that, I am not particularly against adding prioritization scheme to every event handler (I just think it is unnecessary, but I trust you will provide a good
example shortly).<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>
<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>Tuesday, May 7, 2024 at 01:44<br>
<b>To: </b><br>
<b>Cc: </b>openjfx-dev@openjdk.org <openjfx-dev@openjdk.org><br>
<b>Subject: </b>Re: Proposal: Public InputMap (v2)<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">Hi Andy!<br>
<br>
The updated proposal seems to be a slight refinement of the original<br>
proposal, and I think most of the points raised in the previous<br>
discussion still stand.<br>
<br>
As it is, I still think that this is an exceptionally large API<br>
surface for what the feature can actually bring to the table. It's<br>
overly specific in trying to solve problems for which general-purpose<br>
APIs like event handlers can be extended to work just as well (and<br>
open up many more use cases than just those of a bespoke control API).<br>
<br>
The fact that the API tries to fix a problem with the event system<br>
itself (unpredictable invocation order) is a red flag. We should fix<br>
this problem where it originates, which is the event API; crafting<br>
workaround APIs in other parts of JavaFX doesn't seem to be the right<br>
approach to me. This would also help to break the problem down into<br>
more manageable chunks: improve the event system first, then see how<br>
that influences the remaining problems that need to be solved.<br>
<br>
You provide several examples of what the InputMap API can do:<br>
<br>
<br>
1. Adding a new key mapping<br>
<br>
// creates a new key binding mapped to an external function<br>
control.getInputMap().registerKey(KeyBinding.shortcut(KeyCode.W), () -> {<br>
externalFunction();<br>
});<br>
<br>
I don't see why this is needed. It doesn't seem to be easier than<br>
using a plain old event handler, it's just different.<br>
<br>
<br>
2. Redefine an existing function<br>
<br>
// redefine function keeping existing key mappings<br>
getInputMap().registerFunction(Tag.COPY, (control) -> customCopy());<br>
<br>
If I want to change the meaning of the copy() method, can I not just<br>
override the method and provide my own implementation? Plain old Java<br>
seems to do the job.<br>
<br>
<br>
3. Map an existing function to a new binding<br>
<br>
// map a new key binding<br>
control.getInputMap().registerKey(KeyBinding.shortcut(KeyCode.W), Tag.COPY);<br>
<br>
Again, an event handler would do the job here.<br>
<br>
<br>
4. Obtain the default function<br>
<br>
// obtains the default function handler<br>
FunctionHandler<?> h = getInputMap().getDefaultFunction(Tag.COPY);<br>
<br>
If I override the copy() method to provide my own implementation, I<br>
could also add a defaultCopy() method that calls the base<br>
implementation. Then I can call both copy() and defaultCopy().<br>
(I don't know why I would want to do this, though.)<br>
<br>
<br>
To summarize: the way I see it, your examples don't provide a<br>
compelling reason why we need this new API. Given the size and<br>
complexity of the proposal, I suggest to break the problem down into<br>
more manageable parts, and solve the most fundamental issues first. At<br>
the very least, the issue with event invocation ordering should be<br>
solved in the event system.<br>
<br>
<br>
<br>
On Mon, Mar 11, 2024 at 4:22</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 JavaFX developers:<br>
><br>
><br>
><br>
> Thank you all for your feedback on my earlier Behavior/InputMap proposal [6], [7]. There was some positive reaction to the idea of allowing for easy customization of JavaFX controls behavior, as well as some push back. Some of the objections were:<br>
><br>
><br>
><br>
> desire for some static behavior to avoid the per-instance penalty<br>
> clearer separation of concerns between controls, skins, and behaviors<br>
> desire to have some sort of public API for behaviors<br>
> need for addressing an issue with the event handler execution order between application and skins<br>
><br>
><br>
><br>
> I would like to restart the discussion by submitting the updated proposal [0] which addresses the issues raised earlier. The new proposal retains the idea of allowing wider customization of key mappings via the InputMap. The new features include:<br>
><br>
><br>
><br>
> separation of SkinInputMap from the control's InputMap<br>
> enabling static skin input maps for stateless behaviors<br>
> explicit priority levels for event handlers and key mappings created by the application and by the skin<br>
><br>
><br>
><br>
> The ideas put forth in this proposal have been validated with the proof-of-concept migration of some non-trivial controls:<br>
><br>
><br>
><br>
> complex popup-like controls: ComboBox, ColorPicker, DatePicker<br>
> complex text input controls: PasswordField, TextArea, TextField<br>
> control with a stateless behavior: TabPane<br>
><br>
><br>
><br>
> as well as a brand new RichTextArea control being incubated [8].<br>
><br>
><br>
><br>
> Please take a look at the proposal [0], a list of discussion points [1], and the API Specification (javadoc) [2]. While the proposed API is ready for review, it isn't complete nor set in stone. We are looking for feedback, and will update the proposal based
on the suggestions we receive from the community. We encourage you to comment either in the mailing list, or by leaving comments inline in a draft pull request [3].<br>
><br>
><br>
><br>
> For context, the links to the original RFE [4] and the earlier proposals [6], [7] are provided below.<br>
><br>
><br>
><br>
> What do you think?<br>
><br>
> -andy<br>
><br>
><br>
><br>
><br>
><br>
> References<br>
><br>
><br>
><br>
> [0] Proposal: <a href="https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV2.md">
https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV2.md</a><br>
><br>
> [1] Discussion points: <a href="https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV2-Discussion.md">
https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV2-Discussion.md</a><br>
><br>
> [2] API specification (javadoc): <a href="https://cr.openjdk.org/~angorya/InputMapV2/javadoc/">
https://cr.openjdk.org/~angorya/InputMapV2/javadoc/</a><br>
><br>
> [3] Draft Pull Request for API comments and feedback: <a href="https://github.com/openjdk/jfx/pull/1395">
https://github.com/openjdk/jfx/pull/1395</a><br>
><br>
> [4] Public InputMap RFE: <a href="https://bugs.openjdk.org/browse/JDK-8314968">
https://bugs.openjdk.org/browse/JDK-8314968</a><br>
><br>
> [5] Documenting behaviors (WIP): <a href="https://github.com/openjdk/jfx/tree/master/doc-files/behavior">
https://github.com/openjdk/jfx/tree/master/doc-files/behavior</a><br>
><br>
> [6] Earlier proposal: <a href="https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/BehaviorInputMapProposal.md">
https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/BehaviorInputMapProposal.md</a><br>
><br>
> [7] Earlier proposal in the OpenJFX mailing list: <a href="https://mail.openjdk.org/pipermail/openjfx-dev/2023-September/042819.html">
https://mail.openjdk.org/pipermail/openjfx-dev/2023-September/042819.html</a><br>
><br>
> [8] RichTextArea (Incubator) <a href="https://github.com/andy-goryachev-oracle/Test/blob/rich.jep.review/doc/RichTextArea/RichTextArea.md">
https://github.com/andy-goryachev-oracle/Test/blob/rich.jep.review/doc/RichTextArea/RichTextArea.md</a><br>
><br>
><o:p></o:p></span></p>
</div>
</div>
</div>
</div>
</body>
</html>