<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">On 31/10/2023 21:03, Andy Goryachev
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:DM5PR1001MB217219E441FA27F2E190C9EAE5A0A@DM5PR1001MB2172.namprd10.prod.outlook.com">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<meta name="Generator" content="Microsoft Word 15 (filtered
medium)">
<style>@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: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;}@font-face
{font-family:"\@Yu Gothic";
panose-1:2 11 4 0 0 0 0 0 0 0;}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;}p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}span.apple-converted-space
{mso-style-name:apple-converted-space;}span.EmailStyle20
{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;}div.WordSection1
{page:WordSection1;}ol
{margin-bottom:0in;}ul
{margin-bottom:0in;}</style>
<div class="WordSection1">
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Iosevka Fixed
SS16"">Dear Martin:<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" style="margin-left:.5in"><span
style="font-size:11.0pt">I understand John’s point: you want
all the user installed filters and handlers across all
levels to be processed before switching to system level
processing. I also understand this prioritization proposal
is designed to push our existing set of system handlers to a
separate phase. But is that all we’re talking about here? I
need some clarification.<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"">If I understand this correctly, this proposal
advocates making drastic changes to the event handling
mechanism. Not only it introduces the prioritization scheme
(which I support), but it also alters the way events are
bubbled up, by introducing waves/phases. I am afraid I
don’t see the use case for doing that. In my opinion, the
prioritization scheme should work on handlers added to the
same EventTarget. There should be no multiple waves - if an
event gets consumed by an event handler, the dispatching
should stop (that change I also support), if not - it
bubbles up the hierarchy.</span></p>
</div>
</blockquote>
<p>The waves (or calling of registered default handlers at the end)
are needed to also allow users to install handlers at ancestors
that would take priority over system handlers. System handlers
really shouldn't touch events unless they fully bubbled up, so the
illusion that user event handlers are the sole event handlers in
existance is being maintained.<br>
</p>
<p>The fact that event handler lists are being shared currently is
incredibly confusing, so that when I do
`scene.addEventHandler(KeyEvent.KEY_PRESSED)` I won't see
navigation keys because they are all consumed by a focused
control. Instead, I should be seeing them, and if I choose not to
act on them, only then should those events be used for
navigation. The current scheme is very business orientated (why
would you ever not want to have navigation keys consumed?), while
other use cases may simply want to disable keyboard control
altogether (games) or have other more important uses for the
cursor keys (like scrolling a map that does have clickable
controls).</p>
<p>Of course, this would need to be done in a backwards compatible
way as it has been this way for quite a while, so sure it you
might see it as drastic, but its compatible, fixes a real flaw in
FX event handling (unpredictability), allows several requested use
cases (albeit at a low level), and its flexiblity will open up new
ways of solving problems we haven't even thought of yet.<span
style="font-size:11.0pt;font-family:"Iosevka Fixed
SS16""><o:p> <br>
</o:p></span></p>
<blockquote type="cite"
cite="mid:DM5PR1001MB217219E441FA27F2E190C9EAE5A0A@DM5PR1001MB2172.namprd10.prod.outlook.com">
<div class="WordSection1">
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Iosevka Fixed
SS16""><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:.5in"><span
style="font-size:11.0pt">Within a given control the order of
event processing gets involved. If a Control is subclassed
the subclass should get first shot at the event. The same is
true for Behaviors and Skins. Beyond that I’m still not
clear if the behavior or skin should get the event first or
if the skin should get it via the behavior or the other way
around. In any case, you’ve got the control, the behavior,
the skin, and all of their subclasses trying to sort out the
execution order.<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"">Hmmm. I am not sure I understand exactly what
you are saying.<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 understand this prioritization
proposal is that we introduce a priority associated with the
handler (and not the filter). The proposal specifies 3
priority levels, I think there might be more, or perhaps we
even have an int priority (might be too much freedom, let’s
discuss).<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"">Specifically, I think there might be 5 levels,
from high to low (the names are just for the purposes of
discussion):<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"">{ AppHigh, SkinHigh, AppMedium, SkinLow, AppLow
}<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"">This way there is absolutely no ambiguity in
deciding which handler gets invoked first. I must note that
SkinHigh, SkinLow should not be available to the application
code. At the same time, AppHigh,AppMedium,AppLow levels
should not be available to skins/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"">Side question: should filters also have
priority?</span></p>
</div>
</blockquote>
<p>I think we're over thinking it. Such fine grained priorities are
not needed. There are two parties involved, the user and JavaFX,
hence two priorities should be enough. FX can be responsible for
ensuring its Skin/Behavior handlers are installed in the right
order (they already have to do that), and users can be responsible
for sorting out their own event handler order (they are after all
in full control of that). <br>
</p>
<p>Alternatively, we can have no priorities and instead only have a
mechanism that allows event handlers to forego handling an event,
but register an interest in handling it if it is unconsumed (after
dispatching completes for filters, or after bubbling completes for
handler if we're inclined to offer both) -- I call these default
handlers, similar to how there is a default exception handler on
each Thread, each Event can have a (list of) default handlers.<br>
</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:DM5PR1001MB217219E441FA27F2E190C9EAE5A0A@DM5PR1001MB2172.namprd10.prod.outlook.com">
<div class="WordSection1">
<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" style="margin-left:.5in"><span
style="font-size:11.0pt">Based on this discussion (and I
might be mistaken on this) it sounds like you're trying to
handle all this using this proposal, namely registering
event handlers with a prioritization scheme.</span><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"">Wait, I though that’s what you are proposing,
based on the doc
<a
href="https://gist.github.com/mstr2/4bde9c97dcf608a0501030ade1ae7dc1"
moz-do-not-send="true" class="moz-txt-link-freetext">https://gist.github.com/mstr2/4bde9c97dcf608a0501030ade1ae7dc1</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"">Are you proposing something else, or is
something missing from the doc?<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" style="margin-left:.5in"><span
style="font-size:11.0pt">Wouldn’t it be easier to just grab
the event and pass it around using Java method calls?
Perhaps the call is handleEvent(). A control implements
handleEvent() by passing the event off to the behavior’s
handleEvent() which passes it off to the skin’s
handleEvent(). The skin sends it up the superclass chain by
calling super.handleEvent(), etc. so on.</span><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"">Wouldn’t this be a drastic departure from the
established event handling method? Why call an empty method
if we are not interested in the event? Or maybe I
misunderstood you here, what are you asking?<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"">To summarize, I think the idea of explicit
priority is a good idea as it solves the current issue or
exact ordering of handlers in the event of skin change, to
give one example. I think we might also benefit from a
limited set of priorities (5) that reflect the reality of fx
having two sides - the application side and the “system”, or
skin/behavior, side.<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"">Personally, I find some other ideas problematic:
I don’t see a good use case for multiple waves in
dispatching, as this represent a major departure from the
current mechanism, unless I am missing something.<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 the paragraph about
subclassing. Perhaps you mean that if we have a situation
where one class extends the other, they should coordinate
the event handling. For example, the base class would
declare the handling method, register it as a listener, for
the child class to override and get the events? Or the base
class should not add any handlers, instead leaving it up to
the child class? But that’s implementation detail.<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>
<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">Martin
Fox <a class="moz-txt-link-rfc2396E" href="mailto:martin@martinfox.com"><martin@martinfox.com></a><br>
<b>Date: </b>Tuesday, October 31, 2023 at 10:13<br>
<b>To: </b>Andy Goryachev
<a class="moz-txt-link-rfc2396E" href="mailto:andy.goryachev@oracle.com"><andy.goryachev@oracle.com></a><br>
<b>Cc: </b>Michael Strauß
<a class="moz-txt-link-rfc2396E" href="mailto:michaelstrau2@gmail.com"><michaelstrau2@gmail.com></a>, openjfx-dev
<a class="moz-txt-link-rfc2396E" href="mailto:openjfx-dev@openjdk.org"><openjfx-dev@openjdk.org></a><br>
<b>Subject: </b>[External] : Re: Prioritized event
handlers<o:p></o:p></span></p>
</div>
<p class="MsoNormal"><span style="font-size:11.0pt">I
understand John’s point: you want all the user installed
filters and handlers across all levels to be processed
before switching to system level processing. I also
understand this prioritization proposal is designed to
push our existing set of system handlers to a separate
phase. But is that all we’re talking about here? I need
some clarification.<o:p></o:p></span></p>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">Within
a given control the order of event processing gets
involved. If a Control is subclassed the subclass
should get first shot at the event. The same is true
for Behaviors and Skins. Beyond that I’m still not
clear if the behavior or skin should get the event
first or if the skin should get it via the behavior or
the other way around. In any case, you’ve got the
control, the behavior, the skin, and all of their
subclasses trying to sort out the execution order.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">Based
on this discussion (and I might be mistaken on this)
it sounds like you're trying to handle all this using
this proposal, namely registering event handlers with
a prioritization scheme. Wouldn’t it be easier to just
grab the event and pass it around using Java method
calls? Perhaps the call is handleEvent(). A control
implements handleEvent() by passing the event off to
the behavior’s handleEvent() which passes it off to
the skin’s handleEvent(). The skin sends it up the
superclass chain by calling super.handleEvent(), etc.
so on.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">This
would make for an easy sell to outside developers. We
can tell them that if they subclass a Control and
implement handleEvent() they will get events first
during the system phase. The same is true if they
subclass a behavior or skin. They don’t need to buy
into or even see a complicated event prioritization
scheme to get exactly what they expect, namely first
access to events.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">But,
again, maybe I’m off base here. Let me know.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">Martin<o:p></o:p></span></p>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt"><br>
<br>
<o:p></o:p></span></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">On
Oct 30, 2023, at 12:53 PM, Andy Goryachev
<a class="moz-txt-link-rfc2396E" href="mailto:andy.goryachev@oracle.com"><andy.goryachev@oracle.com></a> wrote:<o:p></o:p></span></p>
</div>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<div>
<div>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Iosevka
Fixed SS16"">Dear Michael:</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Iosevka
Fixed SS16""> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Iosevka
Fixed SS16"">Thank you, this is very
helpful.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Iosevka
Fixed SS16""> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Iosevka
Fixed SS16"">Questions/Comments:</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Iosevka
Fixed SS16""> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Iosevka
Fixed SS16"">1. Does this proposal
changes the way events are dispatched with
respect to priority? In other words, does it
first go through the list of all handlers
registred on the leaf Node (high priority
first, then lower, then lowest), then bubble
up? Or do they propagate upwards looking for
high priority handlers first, then the process
restarts for lower priorities, as I saw in
some previous emails? (I could be mistaken)</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Iosevka
Fixed SS16""> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Iosevka
Fixed SS16"">2. Do you propose to abort
event dispatching immediately after the event
is consumed? This probably should be
mentioned earlier in the Motivation (the
problem statement) section.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Iosevka
Fixed SS16""> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Iosevka
Fixed SS16"">3. I wonder if three
priority levels are sufficient. Let me
explain. We have two possible actors who can
register an event listener: the application
code and the FX (or, rather more specifically,
the skin and its behavior, whatever that might
be).</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Iosevka
Fixed SS16""> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Iosevka
Fixed SS16"">Application code might want
to add handlers at three possible priorities:</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Iosevka
Fixed SS16""> </span><o:p></o:p></p>
</div>
<ul style="margin-top:0in" type="disc">
<li class="MsoListParagraph"
style="margin-top:0in;margin-bottom:0in;mso-list:l1
level1 lfo1">
<span style="font-family:"Iosevka Fixed
SS16"">App handler must always be called
before any fx handler</span><span
style="font-size:10.0pt"><o:p></o:p></span></li>
<li class="MsoListParagraph"
style="margin-top:0in;margin-bottom:0in;mso-list:l1
level1 lfo1">
<span style="font-family:"Iosevka Fixed
SS16"">App hander does not care</span><span
style="font-size:10.0pt"><o:p></o:p></span></li>
<li class="MsoListParagraph"
style="margin-top:0in;margin-bottom:0in;mso-list:l1
level1 lfo1">
<span style="font-family:"Iosevka Fixed
SS16"">App handler must always be called
after any fx handlers</span><span
style="font-size:10.0pt"><o:p></o:p></span></li>
</ul>
<div>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Iosevka
Fixed SS16""> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Iosevka
Fixed SS16"">For fx/skin handlers we
might have fewer levels:</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Iosevka
Fixed SS16""> </span><o:p></o:p></p>
</div>
<ul style="margin-top:0in" type="disc">
<li class="MsoListParagraph"
style="margin-top:0in;margin-bottom:0in;mso-list:l0
level1 lfo2">
<span style="font-family:"Iosevka Fixed
SS16"">Skin handler does not care</span><span
style="font-size:10.0pt"><o:p></o:p></span></li>
<li class="MsoListParagraph"
style="margin-top:0in;margin-bottom:0in;mso-list:l0
level1 lfo2">
<span style="font-family:"Iosevka Fixed
SS16"">Skin handler must be called after
all other skin handlers</span><span
style="font-size:10.0pt"><o:p></o:p></span></li>
</ul>
<div>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Iosevka
Fixed SS16""> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Iosevka
Fixed SS16"">This situation maps to 5
priorities and 4 effective levels (or 5).</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Iosevka
Fixed SS16""> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Iosevka
Fixed SS16"">We should also mention the
fact that when any actor adds two or more
handlers for the same event with the same
priority, they get invoked in the order added.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Iosevka
Fixed SS16""> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Iosevka
Fixed SS16"">Would you agree, or am I
missing some critical aspect of the proposed
solution?</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Iosevka
Fixed SS16""> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Iosevka
Fixed SS16"">Thank you</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Iosevka
Fixed SS16"">-andy</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Iosevka
Fixed SS16""> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Iosevka
Fixed SS16""> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Iosevka
Fixed SS16""> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Iosevka
Fixed SS16""> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Iosevka
Fixed SS16""> </span><o:p></o:p></p>
</div>
<div id="mail-editor-reference-message-container">
<div>
<div style="border:none;border-top:solid
windowtext 1.0pt;padding:3.0pt 0in 0in
0in;border-color:currentcolor
currentcolor;border-image: none">
<p class="MsoNormal"
style="margin-bottom:12.0pt"><b><span
style="font-size:12.0pt">From:<span
class="apple-converted-space"> </span></span></b><span
style="font-size:12.0pt">openjfx-dev
<a class="moz-txt-link-rfc2396E" href="mailto:openjfx-dev-retn@openjdk.org"><openjfx-dev-retn@openjdk.org></a> on
behalf of Michael Strauß
<a class="moz-txt-link-rfc2396E" href="mailto:michaelstrau2@gmail.com"><michaelstrau2@gmail.com></a><br>
<b>Date:<span
class="apple-converted-space"> </span></b>Friday,
October 27, 2023 at 19:41<br>
<b>To:<span class="apple-converted-space"> </span></b>openjfx-dev
<a class="moz-txt-link-rfc2396E" href="mailto:openjfx-dev@openjdk.org"><openjfx-dev@openjdk.org></a><br>
<b>Subject:<span
class="apple-converted-space"> </span></b>Re:
Prioritized event handlers</span><o:p></o:p></p>
</div>
<div>
<div>
<p class="MsoNormal"><span
style="font-size:11.0pt">Here is the
proposal:<br>
<a
href="https://urldefense.com/v3/__https:/gist.github.com/mstr2/4bde9c97dcf608a0501030ade1ae7dc1__;!!ACWV5N9M2RV99hQ!NvO4B-fpHrjczoDGCoctorfNPX48w38MvW-LOf6ElCk0dBqFX_xPlETcr56POnEaBcwENrIOsX4OKDM0OGc07A$"
moz-do-not-send="true">https://gist.github.com/mstr2/4bde9c97dcf608a0501030ade1ae7dc1</a><br>
<br>
Comments are welcome.<br>
<br>
<br>
On Fri, Oct 27, 2023 at 8:21 PM Andy
Goryachev<br>
<a class="moz-txt-link-rfc2396E" href="mailto:andy.goryachev@oracle.com"><andy.goryachev@oracle.com></a> wrote:<br>
><br>
> Would it be possible to create a
proposal in the JEP format outlining the
proposed public API?<br>
><br>
><br>
><br>
> Thank you<br>
><br>
> -andy</span><o:p></o:p></p>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
</div>
</div>
</div>
</div>
</blockquote>
</body>
</html>