[prev in list] [next in list] [prev in thread] [next in thread]
List: openjdk-openjfx-dev
Subject: Re: [External] : Re: Prioritized event handlers
From: Andy Goryachev <andy.goryachev () oracle ! com>
Date: 2023-10-31 23:05:16
Message-ID: DM5PR1001MB2172E0E89034EF4A5F0860D1E5A0A () DM5PR1001MB2172 ! namprd10 ! prod ! outlook ! com
[Download RAW message or body]
[Attachment #2 (text/plain)]
Dear John:
I am not convinced. I think there is no need for an extra mechanism (I am referring \
to waves), the scenario you are describing here
that when I do `scene.addEventHandler(KeyEvent.KEY_PRESSED)` I won't see navigation \
keys because they are all consumed by a focused control.
should, in my opinion, be implemented via addEventFilter() on the container or the \
scene.
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.
Hm. We need two priorities for skins, and if the application side wants to add a \
handler that is guaranteed to be invoked first or last regardless of skin change, we \
need at least two more. So two priorities are clearly not enough.
-andy
From: openjfx-dev <openjfx-dev-retn@openjdk.org> on behalf of John Hendrikx \
<john.hendrikx@gmail.com>
Date: Tuesday, October 31, 2023 at 15:10
To: openjfx-dev@openjdk.org <openjfx-dev@openjdk.org>
Subject: Re: [External] : Re: Prioritized event handlers
On 31/10/2023 21:03, Andy Goryachev wrote:
Dear Martin:
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.
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.
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.
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).
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.
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.
Hmmm. I am not sure I understand exactly what you are saying.
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).
Specifically, I think there might be 5 levels, from high to low (the names are just \
for the purposes of discussion):
{ AppHigh, SkinHigh, AppMedium, SkinLow, AppLow }
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.
Side question: should filters also have priority?
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).
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.
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.
Wait, I though that's what you are proposing, based on the doc \
https://gist.github.com/mstr2/4bde9c97dcf608a0501030ade1ae7dc1
Are you proposing something else, or is something missing from the doc?
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.
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?
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.
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.
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.
What do you think?
-andy
From: Martin Fox <martin@martinfox.com><mailto:martin@martinfox.com>
Date: Tuesday, October 31, 2023 at 10:13
To: Andy Goryachev <andy.goryachev@oracle.com><mailto:andy.goryachev@oracle.com>
Cc: Michael Strauß <michaelstrau2@gmail.com><mailto:michaelstrau2@gmail.com>, \
openjfx-dev <openjfx-dev@openjdk.org><mailto:openjfx-dev@openjdk.org>
Subject: [External] : Re: Prioritized event handlers
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.
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.
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.
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.
But, again, maybe I'm off base here. Let me know.
Martin
On Oct 30, 2023, at 12:53 PM, Andy Goryachev \
<andy.goryachev@oracle.com><mailto:andy.goryachev@oracle.com> wrote:
Dear Michael:
Thank you, this is very helpful.
Questions/Comments:
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)
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.
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).
Application code might want to add handlers at three possible priorities:
1. App handler must always be called before any fx handler
2. App hander does not care
3. App handler must always be called after any fx handlers
For fx/skin handlers we might have fewer levels:
1. Skin handler does not care
2. Skin handler must be called after all other skin handlers
This situation maps to 5 priorities and 4 effective levels (or 5).
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.
Would you agree, or am I missing some critical aspect of the proposed solution?
Thank you
-andy
From: openjfx-dev <openjfx-dev-retn@openjdk.org><mailto:openjfx-dev-retn@openjdk.org> \
on behalf of Michael Strauß \
<michaelstrau2@gmail.com><mailto:michaelstrau2@gmail.com>
Date: Friday, October 27, 2023 at 19:41
To: openjfx-dev <openjfx-dev@openjdk.org><mailto:openjfx-dev@openjdk.org>
Subject: Re: Prioritized event handlers
Here is the proposal:
https://gist.github.com/mstr2/4bde9c97dcf608a0501030ade1ae7dc1<https://urldefense.com/ \
v3/__https:/gist.github.com/mstr2/4bde9c97dcf608a0501030ade1ae7dc1__;!!ACWV5N9M2RV99hQ \
!NvO4B-fpHrjczoDGCoctorfNPX48w38MvW-LOf6ElCk0dBqFX_xPlETcr56POnEaBcwENrIOsX4OKDM0OGc07A$>
Comments are welcome.
On Fri, Oct 27, 2023 at 8:21 PM Andy Goryachev
<andy.goryachev@oracle.com><mailto:andy.goryachev@oracle.com> wrote:
>
> Would it be possible to create a proposal in the JEP format outlining the proposed \
> public API?
>
>
> Thank you
>
> -andy
[Attachment #3 (text/html)]
<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: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;}
@font-face
{font-family:"Iosevka Fixed SS16 ";
panose-1:2 0 5 9 3 0 0 0 0 4;}
/* Style Definitions */
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.EmailStyle22
{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;}
/* List Definitions */
@list l0
{mso-list-id:849681604;
mso-list-template-ids:-1790805608;}
@list l0:level1
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level2
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level3
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level4
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level5
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level6
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level7
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level8
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level9
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1
{mso-list-id:943923403;
mso-list-template-ids:2077398812;}
@list l1:level1
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level2
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level3
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level4
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level5
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level6
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level7
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level8
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level9
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l2
{mso-list-id:1049496644;
mso-list-template-ids:-1688435102;}
@list l2:level1
{mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level2
{mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level3
{mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level4
{mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level5
{mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level6
{mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level7
{mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level8
{mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level9
{mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l3
{mso-list-id:2033530457;
mso-list-template-ids:1484141864;}
@list l3:level1
{mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l3:level2
{mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l3:level3
{mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l3:level4
{mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l3:level5
{mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l3:level6
{mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l3:level7
{mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l3:level8
{mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l3:level9
{mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></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 John:<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 am not \
convinced. I think there is no need for an extra mechanism (I am referring to \
waves), the scenario you are describing 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" \
style="margin-left:.5in">that when I do `scene.addEventHandler(KeyEvent.KEY_PRESSED)` \
I won't see navigation keys because they are all consumed by a focused control.<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"">should, in my \
opinion, be implemented via addEventFilter() on the container or the \
scene.<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">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. <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"">Hm. We need \
two priorities for skins, and if the application side wants to add a handler that is \
guaranteed to be invoked first or last regardless of skin change, we need at least \
two more. So two priorities are <b><i><u>clearly</u></i></b> not \
enough.<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 John Hendrikx <john.hendrikx@gmail.com><br> <b>Date: </b>Tuesday, \
October 31, 2023 at 15:10<br> <b>To: </b>openjfx-dev@openjdk.org \
<openjfx-dev@openjdk.org><br> <b>Subject: </b>Re: [External] : Re: Prioritized \
event handlers<o:p></o:p></span></p> </div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">On 31/10/2023 21:03, Andy \
Goryachev wrote:<o:p></o:p></span></p> </div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Iosevka Fixed \
SS16 "">Dear Martin:</span><o:p></o:p></p> <p class="MsoNormal"><span \
style="font-size:11.0pt;font-family:"Iosevka Fixed SS16 \
""> </span><o:p></o:p></p> <p class="MsoNormal"><span \
style="font-size:11.0pt;font-family:"Iosevka Fixed SS16 \
""> </span><o:p></o:p></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.</span><o:p></o:p></p> <p class="MsoNormal"><span \
style="font-size:11.0pt;font-family:"Iosevka Fixed SS16 \
""> </span><o:p></o:p></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><o:p></o:p></p> </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.<o:p></o:p></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).<o:p></o:p></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-family:"Iosevka Fixed SS16 ""> <br>
<br>
</span><o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Iosevka Fixed \
SS16 ""> </span><o:p></o:p></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.</span><o:p></o:p></p> <p class="MsoNormal"><span \
style="font-size:11.0pt;font-family:"Iosevka Fixed SS16 \
""> </span><o:p></o:p></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.</span><o:p></o:p></p> <p \
class="MsoNormal"><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16 \
""> </span><o:p></o:p></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).</span><o:p></o:p></p> <p class="MsoNormal"><span \
style="font-size:11.0pt;font-family:"Iosevka Fixed SS16 \
""> </span><o:p></o:p></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):</span><o:p></o:p></p> <p class="MsoNormal"><span \
style="font-size:11.0pt;font-family:"Iosevka Fixed SS16 \
""> </span><o:p></o:p></p> <p class="MsoNormal"><span \
style="font-size:11.0pt;font-family:"Iosevka Fixed SS16 "">{ AppHigh, \
SkinHigh, AppMedium, SkinLow, AppLow }</span><o:p></o:p></p> <p \
class="MsoNormal"><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16 \
""> </span><o:p></o:p></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. </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Iosevka Fixed \
SS16 ""> </span><o:p></o:p></p> <p class="MsoNormal"><span \
style="font-size:11.0pt;font-family:"Iosevka Fixed SS16 "">Side question: \
should filters also have priority?</span><o:p></o:p></p> </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). <o:p></o:p></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.<o:p></o:p></p> \
<p><o:p> </o:p></p> <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Iosevka Fixed \
SS16 ""> </span><o:p></o:p></p> <p class="MsoNormal"><span \
style="font-size:11.0pt;font-family:"Iosevka Fixed SS16 \
""> </span><o:p></o:p></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><o:p></o:p></p> <p class="MsoNormal"><span \
style="font-size:11.0pt;font-family:"Iosevka Fixed SS16 \
""> </span><o:p></o:p></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">https://gist.github.com/mstr2/4bde9c97dcf608a0501030ade1ae7dc1</a></span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Iosevka Fixed \
SS16 ""> </span><o:p></o:p></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?</span><o:p></o:p></p> \
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Iosevka Fixed \
SS16 ""> </span><o:p></o:p></p> <p class="MsoNormal"><span \
style="font-size:11.0pt;font-family:"Iosevka Fixed SS16 \
""> </span><o:p></o:p></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><o:p></o:p></p> <p class="MsoNormal"><span \
style="font-size:11.0pt;font-family:"Iosevka Fixed SS16 \
""> </span><o:p></o:p></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?</span><o:p></o:p></p> <p class="MsoNormal"><span \
style="font-size:11.0pt;font-family:"Iosevka Fixed SS16 \
""> </span><o:p></o:p></p> <p class="MsoNormal"><span \
style="font-size:11.0pt;font-family:"Iosevka Fixed SS16 \
""> </span><o:p></o:p></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.</span><o:p></o:p></p> <p class="MsoNormal"><span \
style="font-size:11.0pt;font-family:"Iosevka Fixed SS16 \
""> </span><o:p></o:p></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.</span><o:p></o:p></p> <p class="MsoNormal"><span \
style="font-size:11.0pt;font-family:"Iosevka Fixed SS16 \
""> </span><o:p></o:p></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.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Iosevka Fixed \
SS16 ""> </span><o:p></o:p></p> <p class="MsoNormal"><span \
style="font-size:11.0pt;font-family:"Iosevka Fixed SS16 "">What do you \
think?</span><o:p></o:p></p> <p class="MsoNormal"><span \
style="font-size:11.0pt;font-family:"Iosevka Fixed SS16 \
""> </span><o:p></o:p></p> <p class="MsoNormal"><span \
style="font-size:11.0pt;font-family:"Iosevka Fixed SS16 \
"">-andy</span><o:p></o:p></p> <p class="MsoNormal"><span \
style="font-size:11.0pt;font-family:"Iosevka Fixed SS16 \
""> </span><o:p></o:p></p> <p class="MsoNormal"><span \
style="font-size:11.0pt;font-family:"Iosevka Fixed SS16 \
""> </span><o:p></o:p></p> <p class="MsoNormal"><span \
style="font-size:11.0pt;font-family:"Iosevka Fixed SS16 \
""> </span><o:p></o:p></p> <p class="MsoNormal"><span \
style="font-size:11.0pt;font-family:"Iosevka Fixed SS16 \
""> </span><o:p></o:p></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 \
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 \
href="mailto:andy.goryachev@oracle.com"><andy.goryachev@oracle.com></a><br> \
<b>Cc: </b>Michael Strauß <a \
href="mailto:michaelstrau2@gmail.com"><michaelstrau2@gmail.com></a>, \
openjfx-dev <a href="mailto:openjfx-dev@openjdk.org"><openjfx-dev@openjdk.org></a><br>
<b>Subject: </b>[External] : Re: Prioritized event handlers</span><o:p></o:p></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.</span><o:p></o:p></p> <div>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span><o:p></o:p></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.</span><o:p></o:p></p> </div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span><o:p></o:p></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.</span><o:p></o:p></p> </div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span><o:p></o:p></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.</span><o:p></o:p></p> </div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">But, again, maybe I'm off base \
here. Let me know.</span><o:p></o:p></p> </div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">Martin</span><o:p></o:p></p>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt"><br>
<br>
<br>
</span><o:p></o:p></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 href="mailto:andy.goryachev@oracle.com"><andy.goryachev@oracle.com></a> \
wrote:</span><o:p></o:p></p> </div>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span><o:p></o:p></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>
<ol style="margin-top:0in" start="1" type="1">
<li class="MsoListParagraph" style="margin-top:0in;margin-bottom:0in;mso-list:l2 \
level1 lfo3"> <span style="font-family:"Iosevka Fixed SS16 "">App handler \
must always be called before any fx handler</span><o:p></o:p></li><li \
class="MsoListParagraph" style="margin-top:0in;margin-bottom:0in;mso-list:l2 level1 \
lfo3"> <span style="font-family:"Iosevka Fixed SS16 "">App hander does not \
care</span><o:p></o:p></li><li class="MsoListParagraph" \
style="margin-top:0in;margin-bottom:0in;mso-list:l2 level1 lfo3"> <span \
style="font-family:"Iosevka Fixed SS16 "">App handler must always be called \
after any fx handlers</span><o:p></o:p></li></ol> <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>
<ol style="margin-top:0in" start="1" type="1">
<li class="MsoListParagraph" style="margin-top:0in;margin-bottom:0in;mso-list:l3 \
level1 lfo6"> <span style="font-family:"Iosevka Fixed SS16 "">Skin handler \
does not care</span><o:p></o:p></li><li class="MsoListParagraph" \
style="margin-top:0in;margin-bottom:0in;mso-list:l3 level1 lfo6"> <span \
style="font-family:"Iosevka Fixed SS16 "">Skin handler must be called after \
all other skin handlers</span><o:p></o:p></li></ol> <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 \
href="mailto:openjfx-dev-retn@openjdk.org"><openjfx-dev-retn@openjdk.org></a> \
on behalf of Michael Strauß <a \
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 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/4bde9c97dcf608a05010 \
30ade1ae7dc1__;!!ACWV5N9M2RV99hQ!NvO4B-fpHrjczoDGCoctorfNPX48w38MvW-LOf6ElCk0dBqFX_xPl \
ETcr56POnEaBcwENrIOsX4OKDM0OGc07A$">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 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"> </span><o:p></o:p></p>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</body>
</html>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic