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
<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
<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/
<https://cr.openjdk.org/~angorya/InputMapV2/javadoc/>
[3] Draft Pull Request for API comments and
feedback:https://github.com/openjdk/jfx/pull/1395
<https://github.com/openjdk/jfx/pull/1395>
[4] Public InputMap RFE:https://bugs.openjdk.org/browse/JDK-8314968
<https://bugs.openjdk.org/browse/JDK-8314968>
[5] Documenting behaviors
(WIP):https://github.com/openjdk/jfx/tree/master/doc-files/behavior
<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
<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
<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
<https://github.com/andy-goryachev-oracle/Test/blob/rich.jep.review/doc/RichTextArea/RichTextArea.md>
