<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:"Yu Gothic";
panose-1:2 11 4 0 0 0 0 0 0 0;}
@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;}
@font-face
{font-family:"\@Yu Gothic";
panose-1:2 11 4 0 0 0 0 0 0 0;}
/* 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.EmailStyle18
{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"">I'd like to understand that too, though the question here might be a slightly different topic (maybe for a separate mail thread).<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 way I look at the problem of using controls as part of other controls (e.g. a TextField inside a Spinner) is that the inner is no longer a fully functional control, in
the sense that it's behavior is different, and governed by the parent control.<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 tried to clarify the separation between various parts in my InputMap proposal (we are not discussing that yet), look at the table in the "Description" section<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16""><a href="https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV3.md">https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV3.md</a><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"">Basically, the control is a façade that hides its internal structure. So when the application is dealing with the Spinner, it should not deal with the TextField, unless there
are public APIs in the Spinner just for that. How the Spinner works is determined by its skin - which can be anything, it can be a 3D knob in some virtual reality with no TextField whatsoever! (Not the case of Spinner, as it actually publishes the TextArea
via its getEditor() 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"">So when we decide to use TextField in a specific SpinnerSkin, we need to modify the way the TextField (being a part of the whole and not the whole) reacts to the external events.
The same goes for decorations, including focus decorations. To show the focused spinner we now draw the focus border around the spinner, not the TextArea. So we need a way to reconfigure the event handling behavior of the TexTField used inside of the Spinner.<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"">Using the InputMap, it's easy to do without subclassing, by simply modifying the InputMap of the inner TextArea. Right now, we have to jump through a number of hoops with
colorful names like setFakeFocus() and so on.<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 trying to get to is that, once the control is a part of another control, it's behavior ("controller" in terms of MVC paradigm) changes, may be even gets substituted
by the "controller" of the parent Control. The parent Control is solely responsible for the new behavior, or we going to have tug of war between two parties.<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 guess my point is - we need a way to customize the behavior, it's useful to both application developers, custom control developers, and the internal skin design, and it's
really easy to do with an InputMap.<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>
<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 Nir Lisker <nlisker@gmail.com><br>
<b>Date: </b>Tuesday, November 12, 2024 at 10:47<br>
<b>To: </b>Kevin Rushforth <kevin.rushforth@oracle.com><br>
<b>Cc: </b>openjfx-dev@openjdk.org <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:12.0pt">I'd like to understand the focus and event handling problem better. If I have a focused TextField, all key events go to it. If I have a Spinner, which is a TextField with 2 Buttons, it is focused as a single
unit and consumes key events whether they are aimed at the text field or the buttons (I assume the buttons handle arrow up/down keys?). If I have a ClolorPicker, it is not focused as a single unit - it has sliders, buttons, text fields and other things, which
can be focused individually.<o:p></o:p></span></p>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt">What I'm trying to find out is what is "the primitive" in the focus/event handling plan. A TextField and a Spinner are treated as primitives, but a ColorPicker and a DatePicker are not. Where does the line
pass? If I'm a controls author, can I create a Spinner that allows focusing/event-handling the text field and the buttons separately, like ColorPicker allows? In this case, Spinner is not a "primitive" control.<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><span style="font-size:12.0pt"><o:p> </o:p></span></p>
<div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt">On Tue, Nov 12, 2024 at 7:56</span><span style="font-size:12.0pt;font-family:"Arial",sans-serif"> </span><span style="font-size:12.0pt">PM Kevin Rushforth <<a href="mailto:kevin.rushforth@oracle.com">kevin.rushforth@oracle.com</a>>
wrote:<o:p></o:p></span></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<p class="MsoNormal"><span style="font-size:12.0pt">I think this is a good discussion to continue. I have a a couple quick comments:<br>
<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:12.0pt">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>
</blockquote>
<p class="MsoNormal"><span style="font-size:12.0pt"><br>
Unless it can be clearly shown that this is a controls-only problem, and never will be something that other users of events need to worry about, I favor a solution in the event handling mechanism itself rather than something controls-specific. So I agree with
Michael on this point.<br>
<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:12.0pt">4, 5. there seems to be general misunderstanding why I see copyFor() as a big problem. (Performance is **not** the issue here).<o:p></o:p></span></p>
</blockquote>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="font-size:12.0pt"><br>
Very likely. I certainly don't see it as a big problem, which suggests I might be missing something. I do find it unlikely that we are going to change something as fundamental as having a target in the event (which is the main reason for using "copyFor").<br>
<br>
-- Kevin<br>
<br>
<o:p></o:p></span></p>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt">On 11/12/2024 8:27 AM, Andy Goryachev wrote:<o:p></o:p></span></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16"">Thank you Michael for answering my questions!</span><span style="font-size:12.0pt"><o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16""> </span><span style="font-size:12.0pt"><o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16"">I get from your answers that:</span><span style="font-size:12.0pt"><o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16""> </span><span style="font-size:12.0pt"><o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><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.</span><span style="font-size:12.0pt"><o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><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.</span><span style="font-size:12.0pt"><o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16"">3. dispatching consumed events looks like a bug to all respondents</span><span style="font-size:12.0pt"><o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><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).</span><span style="font-size:12.0pt"><o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16""> </span><span style="font-size:12.0pt"><o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16"">Please correct me if I summarized it incorrectly.</span><span style="font-size:12.0pt"><o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16""> </span><span style="font-size:12.0pt"><o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><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.</span><span style="font-size:12.0pt"><o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16""> </span><span style="font-size:12.0pt"><o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><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.</span><span style="font-size:12.0pt"><o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16""> </span><span style="font-size:12.0pt"><o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16"">So I would like to ask for clarifications on these three questions:</span><span style="font-size:12.0pt"><o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16""> </span><span style="font-size:12.0pt"><o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><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?</span><span style="font-size:12.0pt"><o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16""> </span><span style="font-size:12.0pt"><o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><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?</span><span style="font-size:12.0pt"><o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16""> </span><span style="font-size:12.0pt"><o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><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?</span><span style="font-size:12.0pt"><o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16""> </span><span style="font-size:12.0pt"><o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16"">Thank you</span><span style="font-size:12.0pt"><o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16"">-andy</span><span style="font-size:12.0pt"><o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16""> </span><span style="font-size:12.0pt"><o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16""> </span><span style="font-size:12.0pt"><o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16""> </span><span style="font-size:12.0pt"><o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16""> </span><span style="font-size:12.0pt"><o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16""> </span><span style="font-size:12.0pt"><o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16""> </span><span style="font-size:12.0pt"><o:p></o:p></span></p>
<div id="m_1220407174510802471mail-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="mso-margin-top-alt:auto;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 <a href="mailto:openjfx-dev-retn@openjdk.org" target="_blank">
<openjfx-dev-retn@openjdk.org></a> on behalf of Michael Strauß <a href="mailto:michaelstrau2@gmail.com" target="_blank">
<michaelstrau2@gmail.com></a><br>
<b>Date: </b>Friday, November 8, 2024 at 17:52<br>
<b>To: </b><br>
<b>Cc: </b>openjfx-dev <a href="mailto:openjfx-dev@openjdk.org" target="_blank"><openjfx-dev@openjdk.org></a><br>
<b>Subject: </b>Re: Prioritized event handlers</span><span style="font-size:12.0pt"><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><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
<a href="mailto:andy.goryachev@oracle.com" target="_blank"><andy.goryachev@oracle.com></a> 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>
></span><span style="font-size:12.0pt"><o:p></o:p></span></p>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<p class="MsoNormal"><span style="font-size:12.0pt"><o:p> </o:p></span></p>
</div>
</blockquote>
</div>
</div>
</div>
</div>
</div>
</body>
</html>