Dear John: Thank you for a thoughtful response!
I am a bit surprised - the point #1 you are trying to make is explicitly supported by the new API. The new API introduces a (fixed) number of priorities to the Controls' event handling specifically to address the issue you've raised earlier. Yes, it is done at the controls' level rather than at the event dispatching level as it was proposed in https://github.com/openjdk/jfx/pull/1266 - for two reasons: 1. doing so at the event dispatching level is a major API change, maybe that's why #1266 went nowhere 2. the only place where fx has this problem is with Controls, since they have to deal with multiple actors, as I explained in my response to Michael's. And the new API is not limited to key events, the priority scheme is extended to any event type. #2. Separation of Behavior and Skins. We went through this a number of times, so let me reiterate my points. Behavior is tied to a particular skin; changing a skin in a drastic way or changing the behavior in a drastic way is possible, if a) there is a need and b) both Skin and its Behavior are made sufficiently public. Alternatively, one must introduce an new API between Skin and its Behavior, which is possible for a particular skin, or a particular control, but I don't think is possible generally. Different skins may require different control surfaces, different gestures, completely different event handling... In any case, this problem I feel is outside of the scope of my proposal. #3. Rock solid primitives. I am all for it! Focus traversal - excellent idea! Let's discuss maybe in a separate thread? But as far as InputMap is concerned, it's a totally different area, out of scope for this proposal. And finally, I disagree with you about incremental changes and fixes. The value of the InputMap it brings to both application and skin developers cannot, I believe, be achieved by incremental steps. Is there something that the proposed APIs that makes it impossible to move forward? Thank you -andy From: openjfx-dev <openjfx-dev-r...@openjdk.org> on behalf of John Hendrikx <john.hendr...@gmail.com> Date: Wednesday, May 15, 2024 at 14:34 To: openjfx-dev@openjdk.org <openjfx-dev@openjdk.org> Subject: Re: Proposal: Public InputMap (v2) I can only second this. If anything, the proposal highlights several fundamental problems in current JavaFX by how it is trying to work around them. The work around works for one area (key events) but does not address similar problems for other events. The work around will also further cement these problems making them harder to address in the future. I'll reiterate what I think are more fundamental issues that should be addressed: 1. Behaviors/Skins/Controls should not be hijacking events for their own purposes before the user has their say in their handling. If the user is not consuming the event (at any level), only then should it fall back to defaults. The reason why it currently works this way is because the public infrastructure for event handling is being used by Skin and Behavior implementations; this infrastructure however by its nature is a first come first serve system (unlike listeners), which makes it risky to share with users unless measures are taken to ensure there are no visible side effects of this sharing. Effectively this also means Skins and Behaviors can *never* add a new event handler, or even a key mapping without risking breaking existing apps. Even consuming a new event in an existing handler, or changing its consumption pattern can cause breakage as it currently stands. 2. Separation of Behaviors and Skins. Even for complex controls this is possible, if there is a willingness to do so. This will open up far easier extension of the FX platform where the choice is not to either throw away all behavior and implement everything yourself, or hope you can sufficiently hack the existing skin (which were never designed for extension) to suit your needs. 3. Provide rock solid control primitives, and provide the infrastructure to build more complicated controls. I should be able to copy/paste any FX control, give it a new name, and then have it behave exactly as the original in all respects. This may mean opening up (or more likely, evaluating and partially redesigning) certain private API's (like focus traversal). I feel strongly that these would provide far more value currently, and, as these are all aspects that can't be addressed easily by 3rd parties or be worked around, only FX developers can solve these. As far as the proposal is concerned, I feel that it is taking a giant leap towards a perceived solution for an X/Y type problem. I think we should be making far smaller incremental changes and fixes, and seeing what those bring. This may eventually lead to an InputMap type system, but it could also lead to a place where the issue to provide it has become less urgent, giving us time to address other more fundamental problems. --John On 07/05/2024 10:44, Michael Strauß wrote: > Hi Andy! > > The updated proposal seems to be a slight refinement of the original > proposal, and I think most of the points raised in the previous > discussion still stand. > > As it is, I still think that this is an exceptionally large API > surface for what the feature can actually bring to the table. It's > overly specific in trying to solve problems for which general-purpose > APIs like event handlers can be extended to work just as well (and > open up many more use cases than just those of a bespoke control API). > > The fact that the API tries to fix a problem with the event system > itself (unpredictable invocation order) is a red flag. We should fix > this problem where it originates, which is the event API; crafting > workaround APIs in other parts of JavaFX doesn't seem to be the right > approach to me. This would also help to break the problem down into > more manageable chunks: improve the event system first, then see how > that influences the remaining problems that need to be solved. > > You provide several examples of what the InputMap API can do: > > > 1. Adding a new key mapping > > // creates a new key binding mapped to an external function > control.getInputMap().registerKey(KeyBinding.shortcut(KeyCode.W), () -> { > externalFunction(); > }); > > I don't see why this is needed. It doesn't seem to be easier than > using a plain old event handler, it's just different. > > > 2. Redefine an existing function > > // redefine function keeping existing key mappings > getInputMap().registerFunction(Tag.COPY, (control) -> customCopy()); > > If I want to change the meaning of the copy() method, can I not just > override the method and provide my own implementation? Plain old Java > seems to do the job. > > > 3. Map an existing function to a new binding > > // map a new key binding > control.getInputMap().registerKey(KeyBinding.shortcut(KeyCode.W), > Tag.COPY); > > Again, an event handler would do the job here. > > > 4. Obtain the default function > > // obtains the default function handler > FunctionHandler<?> h = getInputMap().getDefaultFunction(Tag.COPY); > > If I override the copy() method to provide my own implementation, I > could also add a defaultCopy() method that calls the base > implementation. Then I can call both copy() and defaultCopy(). > (I don't know why I would want to do this, though.) > > > To summarize: the way I see it, your examples don't provide a > compelling reason why we need this new API. Given the size and > complexity of the proposal, I suggest to break the problem down into > more manageable parts, and solve the most fundamental issues first. At > the very least, the issue with event invocation ordering should be > solved in the event system. > > > > On Mon, Mar 11, 2024 at 4:22 PM Andy Goryachev > <andy.goryac...@oracle.com> wrote: >> Dear JavaFX developers: >> >> >> >> Thank you all for your feedback on my earlier Behavior/InputMap proposal >> [6], [7]. There was some positive reaction to the idea of allowing for easy >> customization of JavaFX controls behavior, as well as some push back. Some >> of the objections were: >> >> >> >> desire for some static behavior to avoid the per-instance penalty >> clearer separation of concerns between controls, skins, and behaviors >> desire to have some sort of public API for behaviors >> need for addressing an issue with the event handler execution order between >> application and skins >> >> >> >> I would like to restart the discussion by submitting the updated proposal >> [0] which addresses the issues raised earlier. The new proposal retains the >> idea of allowing wider customization of key mappings via the InputMap. The >> new features include: >> >> >> >> separation of SkinInputMap from the control's InputMap >> enabling static skin input maps for stateless behaviors >> explicit priority levels for event handlers and key mappings created by the >> application and by the skin >> >> >> >> The ideas put forth in this proposal have been validated with the >> proof-of-concept migration of some non-trivial controls: >> >> >> >> complex popup-like controls: ComboBox, ColorPicker, DatePicker >> complex text input controls: PasswordField, TextArea, TextField >> control with a stateless behavior: TabPane >> >> >> >> as well as a brand new RichTextArea control being incubated [8]. >> >> >> >> Please take a look at the proposal [0], a list of discussion points [1], and >> the API Specification (javadoc) [2]. While the proposed API is ready for >> review, it isn't complete nor set in stone. We are looking for feedback, and >> will update the proposal based on the suggestions we receive from the >> community. We encourage you to comment either in the mailing list, or by >> leaving comments inline in a draft pull request [3]. >> >> >> >> For context, the links to the original RFE [4] and the earlier proposals >> [6], [7] are provided below. >> >> >> >> What do you think? >> >> -andy >> >> >> >> >> >> References >> >> >> >> [0] Proposal: >> https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV2.md >> >> [1] Discussion points: >> https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV2-Discussion.md >> >> [2] API specification (javadoc): >> https://cr.openjdk.org/~angorya/InputMapV2/javadoc/ >> >> [3] Draft Pull Request for API comments and feedback: >> https://github.com/openjdk/jfx/pull/1395 >> >> [4] Public InputMap RFE: https://bugs.openjdk.org/browse/JDK-8314968 >> >> [5] Documenting behaviors (WIP): >> https://github.com/openjdk/jfx/tree/master/doc-files/behavior >> >> [6] Earlier proposal: >> https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/BehaviorInputMapProposal.md >> >> [7] Earlier proposal in the OpenJFX mailing list: >> https://mail.openjdk.org/pipermail/openjfx-dev/2023-September/042819.html >> >> [8] RichTextArea (Incubator) >> https://github.com/andy-goryachev-oracle/Test/blob/rich.jep.review/doc/RichTextArea/RichTextArea.md >> >>
