Dear Michael: 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.
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. So, in this spirit - 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). I see that 1. the input map idea adds value (the feedback I’ve been getting pretty much from everyone) 2. it adds a whole bunch of methods (yes it does, for the user and the skin developer) 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) 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. You asked for a use case (I struggle to see a use case for this feature.), 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). 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. 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. 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. 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 :-) To summarize, what exactly is wrong with the proposal, and why? Please be specific. Thank you! -andy From: openjfx-dev <openjfx-dev-r...@openjdk.org> on behalf of Michael Strauß <michaelstr...@gmail.com> Date: Tuesday, October 17, 2023 at 15:56 To: Cc: openjfx-dev@openjdk.org <openjfx-dev@openjdk.org> Subject: Re: [External] : Re: [Request for Comments] Behavior / InputMap Hi Andy, 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. 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. In an earlier mail, you wrote the following: > 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). 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. 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. 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. 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). 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. 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. 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: 1. SVG images!!! 2. I want some XYZ control. 3. By the way, how can I extend and/or modify existing controls and skins? 4. Make JavaFX look more modern. 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. On Tue, Oct 17, 2023 at 8:07 PM Andy Goryachev <andy.goryac...@oracle.com<mailto:andy.goryac...@oracle.com>> wrote: Dear John: It looks like we have different views on the subject, so perhaps we should invite other people to weigh in. 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 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. If nobody uses FX there will be no “later”. If customers’ code breaks too often they will switch to some [unnamed] alternative. 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. We kind of know what behaviors do - they handle user input, modifying the appearance or internal state of the control. 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. Another point is that behavior is sometimes stateful, so let’s take this into account as well. 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. 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. 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. 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. Thank you -andy
