Hi there, Thank you Robert for your feedback! As a fellow application and custom component developer, I can't wait for this feature to get in.
I wonder if anyone else have any objections or feedback, specifically John Hendrikx and Martin Fox. I hope the new proposal addresses the concerns you've raised earlier (support for stateless behaviors and explicit priority of event handlers in Controls), and we can move forward with the feature. Cheers, -andy From: openjfx-dev <openjfx-dev-r...@openjdk.org> on behalf of Robert Lichtenberger <r.lichtenber...@gmail.com> Date: Monday, March 11, 2024 at 23:23 To: openjfx-dev@openjdk.org <openjfx-dev@openjdk.org> Subject: Re: Proposal: Public InputMap (v2) I've had a look into the proposal and I like it a lot. I've had numerous encounters with "little tweaks" to keyboard handling and/or behaviour that I had to work around, all of which would (as far as I can tell) have been avoidable, if this API were in existence. So while there is quite some "API surface", as an application developer I can't wait to see this happening. It will go a long way to make JavaFX more easily usable. --Robert Am 11.03.24 um 16:22 schrieb Andy Goryachev: 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
