<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><div><blockquote type="cite"><div class="WordSection1" style="page: WordSection1; font-family: Optima-Regular;"><div style="margin: 0in; font-size: 10pt; font-family: Calibri, sans-serif;"><span style="font-size: 11pt; font-family: "Iosevka Fixed SS16";">To summarize, what exactly is wrong with the proposal, and why?</span></div></div></blockquote></div><div><br></div><div>Taking the proposal on its own terms…</div><div><br></div><div>1) There’s no reason to make BehaviorBase public. The protocol for building and updating InputMaps is on the control surface and a control may not use a behavior.</div><div><br></div><div>2) The proposal doesn’t break the problem down into components. You need a map from FunctionTag to Runnable. You need a map from KeyEvent to FunctionTag. Do those maps have the same requirements? Should they both be mutable? Can they be re-used in other contexts? Do they need to be in the same object?</div><div><br></div><div>3) The proposal doesn’t separate interface from implementation. Assume the developer needs to provide an object that maps from a KeyEvent to a FunctionTag. You should define an interface for the mapping without imposing an implementation. Behind the scenes a developer could use simple table look up OR an elaborate mechanism that enables end-user customization. It’s not relevant to this proposal.</div><div><br></div><div>4) Looking at the implementation it’s clear that controls are repeating the same bindings over and over. That should signal that you’ve got a maintenance problem and need to design for some degree of centralization.</div><div><br></div><div>5) Are InputMaps being provided as a convenience or a necessity? It turns out the FunctionTag=>Runnable map is a necessity as it provides access to methods that aren’t currently visible via the control’s API. Everything else is convenience. The proposal doesn’t provide this context.</div><div><br></div><div>Martin</div><div><div><br><blockquote type="cite"><div>On Oct 18, 2023, at 12:43 PM, Andy Goryachev <andy.goryachev@oracle.com> wrote:</div><br class="Apple-interchange-newline"><div><meta charset="UTF-8"><div class="WordSection1" style="page: WordSection1; caret-color: rgb(0, 0, 0); font-family: Optima-Regular; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;"><div style="margin: 0in; font-size: 10pt; font-family: Calibri, sans-serif;"><span style="font-size: 11pt; font-family: "Iosevka Fixed SS16";">Dear Michael:<o:p></o:p></span></div><div style="margin: 0in; font-size: 10pt; font-family: Calibri, sans-serif;"><span style="font-size: 11pt; font-family: "Iosevka Fixed SS16";"><o:p> </o:p></span></div><div style="margin: 0in; font-size: 10pt; font-family: Calibri, sans-serif;"><span style="font-size: 11pt; 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></div><div style="margin: 0in; font-size: 10pt; font-family: Calibri, sans-serif;"><span style="font-size: 11pt; font-family: "Iosevka Fixed SS16";"><o:p> </o:p></span></div><div style="margin: 0in; font-size: 10pt; font-family: Calibri, sans-serif;"><span style="font-size: 11pt; 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></div><div style="margin: 0in; font-size: 10pt; font-family: Calibri, sans-serif;"><span style="font-size: 11pt; font-family: "Iosevka Fixed SS16";"><o:p> </o:p></span></div><div style="margin: 0in; font-size: 10pt; font-family: Calibri, sans-serif;"><span style="font-size: 11pt; font-family: "Iosevka Fixed SS16";">So, in this spirit -<o:p></o:p></span></div><div style="margin: 0in; font-size: 10pt; font-family: Calibri, sans-serif;"><span style="font-size: 11pt; font-family: "Iosevka Fixed SS16";"><o:p> </o:p></span></div><div style="margin: 0in 0in 0in 0.5in; font-size: 10pt; font-family: Calibri, sans-serif;"><span style="font-size: 11pt;">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></div><div style="margin: 0in; font-size: 10pt; font-family: Calibri, sans-serif;"><span style="font-size: 11pt; font-family: "Iosevka Fixed SS16";"><o:p> </o:p></span></div><div style="margin: 0in; font-size: 10pt; font-family: Calibri, sans-serif;"><span style="font-size: 11pt; font-family: "Iosevka Fixed SS16";">I see that<o:p></o:p></span></div><div style="margin: 0in; font-size: 10pt; font-family: Calibri, sans-serif;"><span style="font-size: 11pt; font-family: "Iosevka Fixed SS16";"><o:p> </o:p></span></div><div style="margin: 0in; font-size: 10pt; font-family: Calibri, sans-serif;"><span style="font-size: 11pt; 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></div><div style="margin: 0in; font-size: 10pt; font-family: Calibri, sans-serif;"><span style="font-size: 11pt; 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></div><div style="margin: 0in; font-size: 10pt; font-family: Calibri, sans-serif;"><span style="font-size: 11pt; 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></div><div style="margin: 0in; font-size: 10pt; font-family: Calibri, sans-serif;"><span style="font-size: 11pt; font-family: "Iosevka Fixed SS16";"><o:p> </o:p></span></div><div style="margin: 0in 0in 0in 0.5in; font-size: 10pt; font-family: Calibri, sans-serif;"><span style="font-size: 11pt;">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></div><div style="margin: 0in; font-size: 10pt; font-family: Calibri, sans-serif;"><span style="font-size: 11pt; font-family: "Iosevka Fixed SS16";"><o:p> </o:p></span></div><div style="margin: 0in; font-size: 10pt; font-family: Calibri, sans-serif;"><span style="font-size: 11pt; font-family: "Iosevka Fixed SS16";">You asked for a use case (</span><span style="color: rgb(33, 33, 33);">I struggle to see a use case for this feature.</span><span style="font-size: 11pt; 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></div><div style="margin: 0in; font-size: 10pt; font-family: Calibri, sans-serif;"><span style="font-size: 11pt; font-family: "Iosevka Fixed SS16";"><o:p> </o:p></span></div><div style="margin: 0in 0in 0in 0.5in; font-size: 10pt; font-family: Calibri, sans-serif;"><span style="font-size: 11pt;">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></div><div style="margin: 0in; font-size: 10pt; font-family: Calibri, sans-serif;"><span style="font-size: 11pt; font-family: "Iosevka Fixed SS16";"><o:p> </o:p></span></div><div style="margin: 0in; font-size: 10pt; font-family: Calibri, sans-serif;"><span style="font-size: 11pt; 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></div><div style="margin: 0in; font-size: 10pt; font-family: Calibri, sans-serif;"><span style="font-size: 11pt; font-family: "Iosevka Fixed SS16";"><o:p> </o:p></span></div><div style="margin: 0in 0in 0in 0.5in; font-size: 10pt; font-family: Calibri, sans-serif;"><span style="font-size: 11pt;">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></div><div style="margin: 0in; font-size: 10pt; font-family: Calibri, sans-serif;"><span style="font-size: 11pt; font-family: "Iosevka Fixed SS16";"><o:p> </o:p></span></div><div style="margin: 0in; font-size: 10pt; font-family: Calibri, sans-serif;"><span style="font-size: 11pt; 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></div><div style="margin: 0in; font-size: 10pt; font-family: Calibri, sans-serif;"><span style="font-size: 11pt; font-family: "Iosevka Fixed SS16";"><o:p> </o:p></span></div><div style="margin: 0in; font-size: 10pt; font-family: Calibri, sans-serif;"><span style="font-size: 11pt; font-family: "Iosevka Fixed SS16";">To summarize, what exactly is wrong with the proposal, and why? Please be specific.<o:p></o:p></span></div><div style="margin: 0in; font-size: 10pt; font-family: Calibri, sans-serif;"><span style="font-size: 11pt; font-family: "Iosevka Fixed SS16";"><o:p> </o:p></span></div><div style="margin: 0in; font-size: 10pt; font-family: Calibri, sans-serif;"><span style="font-size: 11pt; font-family: "Iosevka Fixed SS16";">Thank you!<o:p></o:p></span></div><div style="margin: 0in; font-size: 10pt; font-family: Calibri, sans-serif;"><span style="font-size: 11pt; font-family: "Iosevka Fixed SS16";">-andy<o:p></o:p></span></div><div style="margin: 0in; font-size: 10pt; font-family: Calibri, sans-serif;"><span style="font-size: 11pt; font-family: "Iosevka Fixed SS16";"><o:p> </o:p></span></div><div style="margin: 0in; font-size: 10pt; font-family: Calibri, sans-serif;"><span style="font-size: 11pt; font-family: "Iosevka Fixed SS16";"><o:p> </o:p></span></div><div style="margin: 0in; font-size: 10pt; font-family: Calibri, sans-serif;"><span style="font-size: 11pt; font-family: "Iosevka Fixed SS16";"><o:p> </o:p></span></div><div id="mail-editor-reference-message-container"><div><div style="border-width: 1pt medium medium; border-style: solid none none; border-color: rgb(181, 196, 223) currentcolor currentcolor; border-image: none; padding: 3pt 0in 0in;"><p class="MsoNormal" style="margin: 0in 0in 12pt; font-size: 10pt; font-family: Calibri, sans-serif;"><b><span style="font-size: 12pt;">From:<span class="Apple-converted-space"> </span></span></b><span style="font-size: 12pt;">openjfx-dev <<a href="mailto:openjfx-dev-retn@openjdk.org" style="color: blue; text-decoration: underline;">openjfx-dev-retn@openjdk.org</a>> on behalf of Michael Strauß <<a href="mailto:michaelstrau2@gmail.com" style="color: blue; text-decoration: underline;">michaelstrau2@gmail.com</a>><br><b>Date:<span class="Apple-converted-space"> </span></b>Tuesday, October 17, 2023 at 15:56<br><b>To:<span class="Apple-converted-space"> </span></b><br><b>Cc:<span class="Apple-converted-space"> </span></b>openjfx-dev@openjdk.org <openjfx-dev@openjdk.org><br><b>Subject:<span class="Apple-converted-space"> </span></b>Re: [External] : Re: [Request for Comments] Behavior / InputMap<o:p></o:p></span></p></div><div><div><div style="margin: 0in; font-size: 10pt; font-family: Calibri, sans-serif;"><span style="font-size: 11pt;">Hi Andy,<o:p></o:p></span></div></div><div><div style="margin: 0in; font-size: 10pt; font-family: Calibri, sans-serif;"><span style="font-size: 11pt;"><o:p> </o:p></span></div></div><div><div style="margin: 0in; font-size: 10pt; font-family: Calibri, sans-serif;"><span style="font-size: 11pt;">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></div></div><div><div style="margin: 0in; font-size: 10pt; font-family: Calibri, sans-serif;"><span style="font-size: 11pt;"><o:p> </o:p></span></div></div><div><div style="margin: 0in; font-size: 10pt; font-family: Calibri, sans-serif;"><span style="font-size: 11pt;">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></div></div><div><div style="margin: 0in; font-size: 10pt; font-family: Calibri, sans-serif;"><span style="font-size: 11pt;"><o:p> </o:p></span></div></div><div><div style="margin: 0in; font-size: 10pt; font-family: Calibri, sans-serif;"><span style="font-size: 11pt;">In an earlier mail, you wrote the following:<o:p></o:p></span></div></div><div><div style="margin: 0in; font-size: 10pt; font-family: Calibri, sans-serif;"><span style="font-size: 11pt;">> 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></div></div><div><div style="margin: 0in; font-size: 10pt; font-family: Calibri, sans-serif;"><span style="font-size: 11pt;"><o:p> </o:p></span></div></div><div><div style="margin: 0in; font-size: 10pt; font-family: Calibri, sans-serif;"><span style="font-size: 11pt;">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></div></div><div><div style="margin: 0in; font-size: 10pt; font-family: Calibri, sans-serif;"><span style="font-size: 11pt;">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></div></div><div><div style="margin: 0in; font-size: 10pt; font-family: Calibri, sans-serif;"><span style="font-size: 11pt;"><o:p> </o:p></span></div></div><div><div style="margin: 0in; font-size: 10pt; font-family: Calibri, sans-serif;"><span style="font-size: 11pt;">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></div></div><div><div style="margin: 0in; font-size: 10pt; font-family: Calibri, sans-serif;"><span style="font-size: 11pt;"><o:p> </o:p></span></div></div><div><div style="margin: 0in; font-size: 10pt; font-family: Calibri, sans-serif;"><span style="font-size: 11pt;">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></div></div><div><div style="margin: 0in; font-size: 10pt; font-family: Calibri, sans-serif;"><span style="font-size: 11pt;"><o:p> </o:p></span></div></div><div><div style="margin: 0in; font-size: 10pt; font-family: Calibri, sans-serif;"><span style="font-size: 11pt;">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></div></div><div><div style="margin: 0in; font-size: 10pt; font-family: Calibri, sans-serif;"><span style="font-size: 11pt;"><o:p> </o:p></span></div></div><div><div style="margin: 0in; font-size: 10pt; font-family: Calibri, sans-serif;"><span style="font-size: 11pt;">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></div></div><div><div style="margin: 0in; font-size: 10pt; font-family: Calibri, sans-serif;"><span style="font-size: 11pt;"><o:p> </o:p></span></div></div><div><div style="margin: 0in; font-size: 10pt; font-family: Calibri, sans-serif;"><span style="font-size: 11pt;">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></div></div><div><div style="margin: 0in; font-size: 10pt; font-family: Calibri, sans-serif;"><span style="font-size: 11pt;"><o:p> </o:p></span></div></div><div><div style="margin: 0in; font-size: 10pt; font-family: Calibri, sans-serif;"><span style="font-size: 11pt;">1. SVG images!!!<o:p></o:p></span></div></div><div><div style="margin: 0in; font-size: 10pt; font-family: Calibri, sans-serif;"><span style="font-size: 11pt;">2. I want some XYZ control.<o:p></o:p></span></div></div><div><div style="margin: 0in; font-size: 10pt; font-family: Calibri, sans-serif;"><span style="font-size: 11pt;">3. By the way, how can I extend and/or modify existing controls and skins?<o:p></o:p></span></div></div><div><div style="margin: 0in; font-size: 10pt; font-family: Calibri, sans-serif;"><span style="font-size: 11pt;">4. Make JavaFX look more modern.<o:p></o:p></span></div></div><div><div style="margin: 0in; font-size: 10pt; font-family: Calibri, sans-serif;"><span style="font-size: 11pt;"><o:p> </o:p></span></div></div><div><div style="margin: 0in; font-size: 10pt; font-family: Calibri, sans-serif;"><span style="font-size: 11pt;">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></div></div><div><div style="margin: 0in; font-size: 10pt; font-family: Calibri, sans-serif;"><span style="font-size: 11pt;"><o:p> </o:p></span></div></div><div style="margin: 0in; font-size: 10pt; font-family: Calibri, sans-serif;"><span style="font-size: 11pt;"><o:p> </o:p></span></div><div><div><div style="margin: 0in; font-size: 10pt; font-family: Calibri, sans-serif;"><span style="font-size: 11pt;">On Tue, Oct 17, 2023 at 8:07 PM Andy Goryachev <<a href="mailto:andy.goryachev@oracle.com" target="_blank" style="color: blue; text-decoration: underline;">andy.goryachev@oracle.com</a>> wrote:<o:p></o:p></span></div></div><blockquote style="border-width: medium medium medium 1pt; border-style: none none none solid; border-color: currentcolor currentcolor currentcolor rgb(204, 204, 204); border-image: none; padding: 0in 0in 0in 6pt; margin-left: 4.8pt; margin-right: 0in;"><div><div><div><div style="margin: 0in; font-size: 10pt; font-family: Calibri, sans-serif;"><span style="font-size: 11pt; font-family: "Iosevka Fixed SS16";">Dear John:</span><span style="font-size: 11pt;"><o:p></o:p></span></div><div style="margin: 0in; font-size: 10pt; font-family: Calibri, sans-serif;"><span style="font-size: 11pt; font-family: "Iosevka Fixed SS16";"> </span><span style="font-size: 11pt;"><o:p></o:p></span></div><div style="margin: 0in; font-size: 10pt; font-family: Calibri, sans-serif;"><span style="font-size: 11pt; 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: 11pt;"><o:p></o:p></span></div><div style="margin: 0in; font-size: 10pt; font-family: Calibri, sans-serif;"><span style="font-size: 11pt; font-family: "Iosevka Fixed SS16";"> </span><span style="font-size: 11pt;"><o:p></o:p></span></div><div style="margin: 0in; font-size: 10pt; font-family: Calibri, sans-serif;"><span style="font-size: 11pt; 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: 11pt;"><o:p></o:p></span></div><div style="margin: 0in; font-size: 10pt; font-family: Calibri, sans-serif;"><span style="font-size: 11pt; font-family: "Iosevka Fixed SS16";"> </span><span style="font-size: 11pt;"><o:p></o:p></span></div><p style="margin-left: 0.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><div style="margin: 0in; font-size: 10pt; font-family: Calibri, sans-serif;"><span style="font-size: 11pt; 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: 11pt;"><o:p></o:p></span></div><div style="margin: 0in; font-size: 10pt; font-family: Calibri, sans-serif;"><span style="font-size: 11pt; font-family: "Iosevka Fixed SS16";"> </span><span style="font-size: 11pt;"><o:p></o:p></span></div><p style="margin-left: 0.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><div style="margin: 0in; font-size: 10pt; font-family: Calibri, sans-serif;"><span style="font-size: 11pt; 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: 11pt;"><o:p></o:p></span></div><div style="margin: 0in; font-size: 10pt; font-family: Calibri, sans-serif;"><span style="font-size: 11pt; font-family: "Iosevka Fixed SS16";"> </span><span style="font-size: 11pt;"><o:p></o:p></span></div><div style="margin: 0in; font-size: 10pt; font-family: Calibri, sans-serif;"><span style="font-size: 11pt; 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: 11pt;"><o:p></o:p></span></div><div style="margin: 0in; font-size: 10pt; font-family: Calibri, sans-serif;"><span style="font-size: 11pt; font-family: "Iosevka Fixed SS16";"> </span><span style="font-size: 11pt;"><o:p></o:p></span></div><div style="margin: 0in; font-size: 10pt; font-family: Calibri, sans-serif;"><span style="font-size: 11pt; 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: 11pt;"><o:p></o:p></span></div><div style="margin: 0in; font-size: 10pt; font-family: Calibri, sans-serif;"><span style="font-size: 11pt; font-family: "Iosevka Fixed SS16";"> </span><span style="font-size: 11pt;"><o:p></o:p></span></div><div style="margin: 0in; font-size: 10pt; font-family: Calibri, sans-serif;"><span style="font-size: 11pt; 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: 11pt;"><o:p></o:p></span></div><div style="margin: 0in; font-size: 10pt; font-family: Calibri, sans-serif;"><span style="font-size: 11pt; font-family: "Iosevka Fixed SS16";"> </span><span style="font-size: 11pt;"><o:p></o:p></span></div><div style="margin: 0in; font-size: 10pt; font-family: Calibri, sans-serif;"><span style="font-size: 11pt; 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: 11pt;"><o:p></o:p></span></div><div style="margin: 0in; font-size: 10pt; font-family: Calibri, sans-serif;"><span style="font-size: 11pt; font-family: "Iosevka Fixed SS16";"> </span><span style="font-size: 11pt;"><o:p></o:p></span></div><div style="margin: 0in; font-size: 10pt; font-family: Calibri, sans-serif;"><span style="font-size: 11pt; 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: 11pt;"><o:p></o:p></span></div><div style="margin: 0in; font-size: 10pt; font-family: Calibri, sans-serif;"><span style="font-size: 11pt; font-family: "Iosevka Fixed SS16";"> </span><span style="font-size: 11pt;"><o:p></o:p></span></div><div style="margin: 0in; font-size: 10pt; font-family: Calibri, sans-serif;"><span style="font-size: 11pt; 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: 11pt;"><o:p></o:p></span></div><div style="margin: 0in; font-size: 10pt; font-family: Calibri, sans-serif;"><span style="font-size: 11pt; font-family: "Iosevka Fixed SS16";"> </span><span style="font-size: 11pt;"><o:p></o:p></span></div><div style="margin: 0in; font-size: 10pt; font-family: Calibri, sans-serif;"><span style="font-size: 11pt; font-family: "Iosevka Fixed SS16";">Thank you</span><span style="font-size: 11pt;"><o:p></o:p></span></div><div style="margin: 0in; font-size: 10pt; font-family: Calibri, sans-serif;"><span style="font-size: 11pt; font-family: "Iosevka Fixed SS16";">-andy</span></div></div></div></div></blockquote></div></div></div></div></div></div></blockquote></div><br></div></body></html>