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> 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 > >
