Proposal: Public InputMap (v2)

Tue May 7 08:44:23 UTC 2024

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.goryachev at 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
>
>