<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;}
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="#467886" vlink="#96607D" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16"">Thank you Michael for answering my questions!<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 get from your answers 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"">1. the priorities are still needed, in one form or the other. Adding a different type of the EH (ifUnconsumed) seems to me like a different priority.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16"">2. the problem seems to exist only at the controls level - nothing was mentioned to cause issues related to priority outside of controls. This seems right, because only in
controls we have two (or more) actors engaged in event handling - the application and the skin.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16"">3. dispatching consumed events looks like a bug to all respondents<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16"">4, 5. there seems to be general misunderstanding why I see copyFor() as a big problem. (Performance is **<b>not**</b> the issue here).<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"">Please correct me if I summarized it incorrectly.<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 interesting observation is that proposals seem to have been replaced by widely different alternatives - ifUnconsumed and event filters. This might indicate that there
is no consensus as of yet, and the discussion must therefore be continued.<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 first question I would like to resolve is to determine whether the problem exists globally, or only at the controls level. If even once scenario exists that does not involve
controls, we must find a solution at the event dispatch level. If not - the solution can be at the controls level, and I have proposed a good solution, but it's premature to talk about it right now.<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 I would like to ask for clarifications on these three questions:<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. For ifUnconsumed idea: how will it work when both the application and the skin register ifUnconsumed EH? Or is it only available to one side, but not the other?<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. For event filter in behaviors idea: how does it work when both behavior and the application register an event filter? and then the skin is changed? wouldn't we have the
same issue?<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. Are there any examples outside of controls where priority inversion happens, or where we need explicit EH priorities for other reasons?<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>
<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>
<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>Friday, November 8, 2024 at 17:52<br>
<b>To: </b><br>
<b>Cc: </b>openjfx-dev <openjfx-dev@openjdk.org><br>
<b>Subject: </b>Re: Prioritized event handlers<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">Hi Andy,<br>
<br>
1. What happened to this proposal?<br>
<br>
I've come to the conclusion that we need something like that, but<br>
probably in a different form. My current thinking is that we don't<br>
need prioritized handlers, but merely a way for interested listeners<br>
to say "I'll take this event, but only if no one else wants it".<br>
A possible API could be something like the following:<br>
<br>
target.addEventHandler(KeyEvent.PRESSED, event -> {<br>
event.ifUnconsumed(evt -> {<br>
// This will be called after the event has bubbled up<br>
// without being consumed.<br>
});<br>
});<br>
<br>
This will allow skins to act on events only if user code didn't consume them.<br>
<br>
2. Does it make sense to change the API at the EventDispatcher level<br>
when the problem can be easily solved by the InputMap at the Control<br>
level?<br>
<br>
Yes, because javafx.controls is not a core part of JavaFX, and it<br>
should never be. People should be free to create their own controls<br>
implementation, or alternative skinning systems. We need to give them<br>
the tools to do so, and not continue the anti-pattern of shifting core<br>
functionality into javafx.controls and special-casing this module even<br>
more than it is already special-cased.<br>
<br>
3. dispatching of events that have been consumed (as mentioned in the<br>
earlier discussion)<br>
<br>
Probably not necessary. Once an event is consumed, it's gone; we don't<br>
need to dispatch it further.<br>
<br>
4. Problem of creating unnecessary clones of events via Event.copyFor()<br>
<br>
Unless there is a clear performance problem, I consider any<br>
fundamental change here as a solution in search of a problem.<br>
Events are usually not so plentiful that we're talking about serious<br>
CPU cycles here. The highest-frequency events are probably mouse<br>
events, and they happen at most hundreds of times per second.<br>
<br>
5. If we removed the target, then a listener couldn't discern whether<br>
the event was targeted at the receiving node, or at a descendant of<br>
the node.<br>
<br>
<br>
<br>
On Thu, Nov 7, 2024 at 1:03</span><span style="font-size:11.0pt;font-family:"Arial",sans-serif"> </span><span style="font-size:11.0pt">AM Andy Goryachev <andy.goryachev@oracle.com> wrote:<br>
><br>
> Dear Michael:<br>
> What happened to this proposal? I would like to restart the discussion, if possible.<br>
><br>
> More specifically, I would like to discuss the following topics:<br>
><br>
> the reason the discussion was started was due to "priority inversion" problem in Controls/Skins, ex.: JDK-8231245 Controls' behavior must not depend on sequence of handler registration. Do we have this problem elsewhere? In other words, does it make sense
to change the API at the EventDispatcher level when the problem can be easily solved by the InputMap at the Control level?<br>
> dispatching of events that have been consumed (as mentioned in the earlier discussion)<br>
> problem of creating unnecessary clones of events via Event.copyFor(), leading to ex.: JDK-8337246 SpinnerSkin does not consume ENTER KeyEvent when editor ActionEvent is consumed<br>
> why do we need Event.copyFor() in the first place? why does Event contain the target??<br>
><o:p></o:p></span></p>
</div>
</div>
</div>
</div>
</div>
</body>
</html>