<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;}
/* 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;}
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;}
@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"">Dear Michael:<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"">Thank you for the feedback! Some of it should, in my opinion, be discussed in a separate email thread (feel free to start one), but let me respond to your comments relevant
to the input map proposal.<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 whole reason we are having this discussion is to come to an agreement. The principles laid out by FX leadership are still there, nobody is trying to rush. At the same
time, as you rightfully pointed out, some things take way too much time (why? separate subject). The thing I’ve been trying to do during discussion is to clearly identify aspects that do or do not work, and why. Suggesting an alternative, in my opinion,
should follow a critical statement. That’s how we’ve got John’s alternative proposal which I consider a valuable side effect of our discussion. So I think we should keep doing it focusing on technical aspects of both proposals.
<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, in this spirit -<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 acknowledge that the InputMap proposal does add value to JavaFX, but it does so at the cost of a pretty large API surface (InputMap has 12 public methods, and BehaviorBase adds another
13 public methods, and that's before going into all of the FunctionTags defined on controls). My feeling is that at last some of that complexity is a result of working around limitations of JavaFX internals (method names like "addHandlerLast" also seem to
suggest that).<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 see that<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"">1. the input map idea adds value (the feedback I’ve been getting pretty much from everyone)<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16"">2. it adds a whole bunch of methods (yes it does, for the user and the skin developer)<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16"">3. limitations of fx internals - I would say it offers similar facility to ease the migration, but you are right about addHandlerLast(), we don’t have a clear way to prioritize
event handlers (this might be a sub-topic of the discussion, because I tend to think the input map might be a good place to offer such a prioritization)
<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">In an earlier mail, I asked you for clarification what this new API enables developers to do. You suggested a customized shortcut feature as seen in Eclipse and other IDEs. John and
Martin observed that an application-level key binding feature most likely wouldn't be implemented using "simple" out-of-the-box tools that JavaFX can offer. In this example, when a shortcut is changed in the IDE, the application wouldn't traverse the whole
scene graph, looking for controls, and then directly manipulating their InputMap in some fashion to enable application-level shortcuts.<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"">You asked for a use case (</span><span style="color:#212121">I struggle to see a use case for this feature.</span><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16"">),
so I provided one. You are right, the Eclipse example is an application feature, but it is enabled by the input map. I’ve also provided other examples. My point is - since the feature is runtime remapping, an immutable input map is out of question. (Note:
it is still possible to have some kind of static secondary map for the standard controls, but that’s an 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" style="margin-left:.5in"><span style="font-size:11.0pt">Since you hinted at RichTextArea, maybe you can talk about how the proposed InputMap is necessary for the new control, and why it can't just use the existing internal impementation
like all other built-in controls.<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 have to apologize and clarify. I am not using RTA as a justification, but as an example. The new input map design has been validated using TextInputControl hierarchy (TextField,
TextArea, PasswordField), ComboBox hierarchy (ComboBox, DatePicker, ColorPicker) and RichTextArea/CodeArea controls for which there will be a separate announcement/discussion a bit later, but it’s in public github anyway.<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">That doesn't mean that key remapping shouldn't be on the list of features we want to implement, but all things considered, I question whether it really is such a forced move to get
this feature in ASAP.<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"">My team believes this is one of the many areas in FX that needs improvement. I don’t think anyone ever said ASAP, it’s a collaborative process and we always try to balance
our own development work and contribution from the community (ghm, #1014 :-)<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, what exactly is wrong with the proposal, and why? Please be specific.<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"">Thank you!<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>
<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 Michael Strauß <michaelstrau2@gmail.com><br>
<b>Date: </b>Tuesday, October 17, 2023 at 15:56<br>
<b>To: </b><br>
<b>Cc: </b>openjfx-dev@openjdk.org <openjfx-dev@openjdk.org><br>
<b>Subject: </b>Re: [External] : Re: [Request for Comments] Behavior / InputMap<o:p></o:p></span></p>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">Hi Andy,<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">I mean this in the most respectful way possible, but my feeling is that most of the arguments presented in favor of this enhancement seem to be driven by an existing implementation, and not a "first-principles"
analysis.<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">I've seen many proposals on this mailing list shot down with exactly this justification: don't simply propose to make an existing internal implementation public; instead, think of it in terms of the problem
and API first. Is the (existing) InputMap idea really so good that it would emerge as the winner in an open competition of ideas? Maybe it is, but I'm not convinced.<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">In an earlier mail, you wrote the following:<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">> BehaviorBase (or an interface with default methods) is an important addition and a pre-requisite for effective use of the new input map (it’s already being used and is a blocker for RichTextArea, and I have
one more control that needs it).<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 puts us in a difficult situation. You're proposing a (controversial) addition to the core JavaFX API, and justify it at least in part with being a blocker for another feature that is presumably already
under development. Again, this is not how feature proposals should be justified according to the guidelines of this project.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">Can't you use the existing internal implementation for RichTextArea, at least for the time being? That would give us a bit more time to let the pieces settle. You've put out the first proposal, which is great!
But now there's at least one other proposal, which is also a great thing.<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">Kevin has rightfully indicated time and time again that we shouldn't rush a new feature into JavaFX, especially if the community hasn't come to a clear agreement. And even if there is an agreement, new features
of this magnitude usually take many months (sometimes years) to go in. Why the urgence for this particular feature? At the same time, other useful features like nested change notifications, CSS transitions, or the whole platform preferences / style themes
saga sit idly by and wait for their time to shine.<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">I acknowledge that the InputMap proposal does add value to JavaFX, but it does so at the cost of a pretty large API surface (InputMap has 12 public methods, and BehaviorBase adds another 13 public methods,
and that's before going into all of the FunctionTags defined on controls). My feeling is that at last some of that complexity is a result of working around limitations of JavaFX internals (method names like "addHandlerLast" also seem to suggest that).<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">In an earlier mail, I asked you for clarification what this new API enables developers to do. You suggested a customized shortcut feature as seen in Eclipse and other IDEs. John and Martin observed that an
application-level key binding feature most likely wouldn't be implemented using "simple" out-of-the-box tools that JavaFX can offer. In this example, when a shortcut is changed in the IDE, the application wouldn't traverse the whole scene graph, looking for
controls, and then directly manipulating their InputMap in some fashion to enable application-level shortcuts.<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">Since you hinted at RichTextArea, maybe you can talk about how the proposed InputMap is necessary for the new control, and why it can't just use the existing internal impementation like all other built-in
controls.<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">You also talk about adding missing features. However, I don't see people requesting key remapping very often (either here on the mailing list, or on other channels like Reddit or StackOverflow). From my observation,
these are the features requested most often:<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">1. SVG images!!!<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">2. I want some XYZ control.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">3. By the way, how can I extend and/or modify existing controls and skins?<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">4. Make JavaFX look more modern.<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">That doesn't mean that key remapping shouldn't be on the list of features we want to implement, but all things considered, I question whether it really is such a forced move to get this feature in ASAP.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt"><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">On Tue, Oct 17, 2023 at 8:07 PM Andy Goryachev <<a href="mailto:andy.goryachev@oracle.com" target="_blank">andy.goryachev@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>
<div>
<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"">Dear John:</span><span style="font-size:11.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:11.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"">It looks like we have different views on the subject, so perhaps we should invite other people to weigh in.</span><span style="font-size:11.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:11.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"">My goal is to move forward adding missing features without making any drastic changes, and avoid regressions as much
as possible. We also have to be mindful of the fact that we are dealing with constrained resources, so any major development is very likely out of question. That’s why</span><span style="font-size:11.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:11.0pt"><o:p></o:p></span></p>
<p style="margin-left:.5in">My problem here is that by making this class public (which IMHO is not a good design) will lock us out of improving this later.
<o:p></o:p></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"">If nobody uses FX there will be no “later”. If customers’ code breaks too often they will switch to some [unnamed]
alternative.</span><span style="font-size:11.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:11.0pt"><o:p></o:p></span></p>
<p style="margin-left:.5in">Nothing Behavior related should be made public without a full design of how Behaviors should work, what their responsibilities are, how they interact with Skins (if at all, IMHO they shouldn't), etc. Once a design is known and agreed
upon, then we can work on step-by-step improvements by making parts public, and leaving parts hidden.<o:p></o:p></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"">We kind of know what behaviors do - they handle user input, modifying the appearance or internal state of the control.</span><span style="font-size:11.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:11.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 just want to mention again that behaviors must interact with skins - not all the behaviors, but some. For example,
TextArea “MOVE_LINE_END” needs to know how the text is laid out in order to determine the target caret position, this function cannot be implemented without the skin and the laid out text. I think we need to take into account this constraint.</span><span style="font-size:11.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:11.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 point is that behavior is sometimes stateful, so let’s take this into account as well.</span><span style="font-size:11.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:11.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 think BehaviorBase is just a convenient way to access the new input map (the subject of the new proposal). If
someone does not want or does not need to use the input map - fine, nothing in the proposed design requires them to use it. I don’t think it should be an interface either - the methods in BehaviorBase are protected because they are offered for subclasses
only, and making BB an interface will turn these public which isn’t right.</span><span style="font-size:11.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:11.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 do acknowledge that the issue of ordering of calls to added handlers might be undefined/unexpected, especially
after a skin change. This is the existing condition, and we probably should try to solve it in a separate thread. I think that for skins the expectation is that the handlers added by the user are orthogonal to those added by the skin/behavior, and if they
are not - use event filter, or let’s talk about adding prioritization in a separate discussion.</span><span style="font-size:11.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:11.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 also acknowledge that the input map proposal does not address the issue of creating alternative custom skins and
extending behaviors beyond modifying the key mappings and some limited manipulations of handlers. But, in my opinion, it adds substantial value to the application developers without upsetting the cart too much.</span><span style="font-size:11.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:11.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"">They say “better is the enemy of good”, which is apt in our case, though I hope we can somehow agree on a solution
in a reasonable time.</span><span style="font-size:11.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:11.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:11.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:11.0pt"><o:p></o:p></span></p>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</div>
</div>
</body>
</html>