<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p><br>
</p>
<div class="moz-cite-prefix">On 23/10/2023 23:57, Andy Goryachev
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:DM5PR1001MB2172C6D7CE63C65D680BF3E0E5D8A@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;}@font-face
{font-family:"Iosevka Fixed SS16 ";
panose-1:2 0 5 9 3 0 0 0 0 4;}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;}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;}</style>
<div class="WordSection1"><span
style="font-size:11.0pt;font-family:"Iosevka Fixed
SS16""><o:p></o:p></span><span
style="font-size:11.0pt;font-family:"Iosevka Fixed
SS16""><o:p> </o:p></span>
<p class="MsoNormal" style="margin-left:.5in">You'd create a new
class, `MyBehavior`,<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"">By “customizing” I also mean at run time.
Creating new classes wouldn’t work.
</span></p>
</div>
</blockquote>
<p>This would also work at runtime, as the class you create can be
instantiated with parameters that control its key binding
behavior. Even though the standard Behaviors should probably be
singletons (so they can be reused and composed) or have public
well documented constructors, a custom behavior created by the
user has no such re-usability restrictions.</p>
<blockquote type="cite"
cite="mid:DM5PR1001MB2172C6D7CE63C65D680BF3E0E5D8A@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" style="margin-left:.5in">coupling<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"">I don’t think it is our choice - it is up to the
skin designed. If they add a node that needs to take input,
or if the behavior is drastically different, it is almost
impossible to create a common interface. So skin and
behaviors are coupled, besides we have to design for the
worst case (of a totally different skin). The division
between S and B comes mostly from the division between V and
C in MVC. From a distance, the user does not see it at all
- all they see is a control.</span></p>
</div>
</blockquote>
<p>JavaFX is not doing MVC.<br>
</p>
In MVC, the 3 components are not entangled; Model refers View,
Controller refers View and Model, View refers nothing; in JavaFX the
View (Skin) creates the Controller (Behavior); the View especially
normally can be created without any dependencies, and can be tested
as such; with Skins being tightly coupled to both Behaviors and
Controls, that doesn't even come close.<br>
<p>For it to be MVC you'd need to:</p>
<p>- Remove reference from Skin to Control<br>
- Do not let Skins create Behaviors<br>
- Instantation order should be, create a Skin first (with no
Control reference), then create the Control (with Skin as
parameter or setter), then create a Behavior (with Control as
parameter, and one or more Views (Skins))</p>
<p>What JavaFX is exactly, I don't know. It doesn't follow MVC
(even though it claims to) because in the current setup the Skin
is both V and C; that's not MVC. At most it is MS (Model Skin),
and so there is no reason to expose anything beyond the Skin then,
as that would just be pretending to be something that it is not.<br>
</p>
<blockquote type="cite"
cite="mid:DM5PR1001MB2172C6D7CE63C65D680BF3E0E5D8A@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"">This suggest another metric at judging the
usefulness of a design - how easy it is to understand and
perform 80% of most common tasks.</span></p>
</div>
</blockquote>
Now that I explained how key remappings would work, I don't see how
this would disqualify the alternative proposal.<br>
<blockquote type="cite"
cite="mid:DM5PR1001MB2172C6D7CE63C65D680BF3E0E5D8A@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"">There are more interesting ideas at the end of
the message I am replying to - fxml, css, global changes -
these go far beyond the simple input map improvement. I did
mention this already, but neither open source community, nor
my employer might have the resources to make such drastic
changes.</span></p>
</div>
</blockquote>
I didn't mention FXML, but yes, I gave some other things to think
about. As for how drastic any of those are, that remains to be
seen. Certainly the global changes would not be that hard at all.
The CSS proposal would need some research if there is some will to
go there; it assumes that the information needed can be transported
in a reasonable manner to the key binding system using the existing
CSS infrastructure.<br>
<blockquote type="cite"
cite="mid:DM5PR1001MB2172C6D7CE63C65D680BF3E0E5D8A@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"">So we have to be realistic, I think. We are
travelling to a different planet in a small spaceship and we
only have so much material and oxygen to play with. A
simple improvement that helps 80% of use cases might be
better than a major redesign (I still think the event
proposal involves major redesign).</span></p>
</div>
</blockquote>
<p>I think that if that's the case that we'd better focus on making
it possible for 3rd parties to deliver these features, and do the
simplest thing that would allow them to do so. That would be
prioritized event handlers (so a 3rd party can always intercept
before the Skin/Behavior gets to it) + a flag to skip system event
handlers (ala consumed) to allow bubbling up.</p>
<p>On top of that any key remapping or behavior change system can be
constructed already.</p>
<p>--John<br>
</p>
</body>
</html>