<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p><br>
</p>
<div class="moz-cite-prefix">On 12/11/2024 18:31, Andy Goryachev
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:BYAPR10MB3013EB63D42A31014544B4D4E5592@BYAPR10MB3013.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: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;}p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:10.0pt;
font-family:"Aptos",sans-serif;}a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Iosevka Fixed SS16";
color:windowtext;}.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;
mso-ligatures:none;}div.WordSection1
{page:WordSection1;}</style>
<div class="WordSection1">
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Iosevka Fixed SS16"">I am
not sure this is the best solution, since it does not solve
the problem of multiple actors adding their event handlers.
I do like the idea of prioritized event handlers, because it
solves the problem *<b>reliably</b>*.<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
think there is no way around it - we need different
priorities. It may be a set or may be a wide range of
integers (for the maximum flexibility), but the main idea is
that, at least in controls, we have a situation where there
are at least these priorities:</span></p>
</div>
</blockquote>
<p>I think if we can find a solution that doesn't require priorities
that it should by far be preferred. You have to think more from a
user perspective. They have a Button, and they add an Event
Handler to do something with the SPACE key. They run their code,
and they find SPACE just disappears and never arrives at their
handler. However, if they add the handler in the Constructor of a
Button subclass, or before the Skin is applied, then the handler
does work. There should not be a difference for the user, because
the Event Handler system does not stipulate that there are
internal handlers that are sharing this infrastructure; for the
user the system looks like it is available solely for their use.</p>
<p>Let's say you now add priorities. What possible reason could a
user have for adding an event handler (for SPACE key) that
wouldn't work (too low priority) or doesn't work reliably (equal
priority)? In other words, the only relevant priority for users
is the one that will make their handler work, which more often
than not will be MAX.</p>
<p>Now let's say we have a Node, and we add several handlers:</p>
<p> Event.ANY (+10)<br>
KeyEvent.KEY_ANY (+20)<br>
KeyEvent.KEY_PRESSED (0)</p>
<p>What order are they going to be called? Without priorities that
would be KEY_PRESSED, KEY_ANY, ANY<br>
</p>
<p>Now let's have a hierarchy of Nodes, A -> B -> C -- I add
the following handlers:<br>
<br>
A: KeyEvent.KEY_PRESSED (+10)<br>
B: KeyEvent.KEY_PRESSED (0)<br>
C: KeyEvent.KEY_PRESSED (+20)<br>
<br>
Which one gets the event first? Does having a handler higher up
the hierarchy trump priorities?<br>
<br>
Providing an alternative solution that doesn't expose the user to
a priority system that further complicates an already complicated
system would be a big win. If we can simply say to the user your
filters/handlers will always go first that's a big win.<br>
</p>
<blockquote type="cite"
cite="mid:BYAPR10MB3013EB63D42A31014544B4D4E5592@BYAPR10MB3013.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"">-
application event filters<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Iosevka Fixed SS16"">-
application event handlers<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Iosevka Fixed SS16"">-
event handlers set by the skin<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Iosevka Fixed SS16"">-
ifUnconsumed-like handlers set by the skin<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Iosevka Fixed SS16"">-
ifUnconsumed-like handlers set by the application<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>
</blockquote>
<p>Let's say a KeyEvent.KEY_PRESSED is fired at a Control
(focusOwner), then the order in which the event can be acted upon
is:<br>
<br>
- Scene hotkeys (Cut/Copy/Paste etc)<br>
- Scene filters (set by user, KeyEvent.KEY_PRESSED first, then
KeyEvent.ANY, then InputEvent.ANY, then Event.ANY)<br>
- Parent filters (set by user, same order as above...)<br>
- Control filters (set by user)<br>
- Control handlers (set by user)<br>
- Parent handlers (set by user)<br>
- Scene handlers (set by user)<br>
- Scene checks unconsumed status, then processes the unconsumed
handlers in order<br>
- Scene default button handling and mnemonic handling (if still
unconsumed at this stage)<br>
<br>
The order of the unconsumed handlers is the order they were
registered in, which depends on where they were called from:<br>
</p>
<p>- ifUnconsumed called by Behavior filters set on Control<br>
- ifUnconsumed called by Skin filters set on Control (possibly to
forward these events to an inner component although they should
only do so when ifUnconsumed calls them back)<br>
- ifUnconsumed called by Behavior handlers set on Control<br>
- ifUnconsumed called by Skin handlers set on Control<br>
<br>
Note that Behavior always has the option to go first (and Skins
should install their internal Behaviors early) by installing a
filter. Behavior's handlers also go first, but can be overridden
by a Skin event filter.<br>
</p>
<p>Also note: the handlers may still get "mixed up" (user/system
handlers), but as all Behavior/Skins will use `ifUnconsumed` and
so go last in all cases, this has become irrelevant.<br>
<br>
SO, neither Skin nor Behavior directly act on any incoming event,
they only register their interest. No Skin internal components
are directly receiving events here. Any event that is directly
targeted at a Skin internal component can use regular means to
handle events as there will not be a conflict with user handlers
as those components are private to the Skin.</p>
<p>--John</p>
<p><br>
</p>
<span style="font-size:11.0pt"><o:p></o:p></span>
<blockquote type="cite"
cite="mid:BYAPR10MB3013EB63D42A31014544B4D4E5592@BYAPR10MB3013.namprd10.prod.outlook.com">
<div class="WordSection1">
<div id="mail-editor-reference-message-container">
<div>
<div>
<div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</body>
</html>