Proposal: Public InputMap (v2)

Tue May 7 15:35:25 UTC 2024

Dear Michael:

Thank you for a thoughtful feedback!

You are correct - the new proposal is a variation of the old one, with modifications intended to address the earlier use cases identified by you and John, namely the event handler priority and the stateless behaviors.

The reason I propose to solve the even priority issue in the Control and its InputMap is simply because I think this is the only place where we have multiple actors shuffling the event handlers: we have the application initial configuration, we have the old skin, possibly the new skin that replaces the old one, and we might have user settings being restored at run time.  I thought the new design addresses these use cases nicely, but it looks like you believe there are use cases that require explicit prioritization of event handlers for things other than Controls.  Can you provide an example please?

As for the second part (items 1-4), I suspect you might be still not considering a use case of user customization at run time or from settings.  To give an example, in the context of a text editor, the user may want to map Ctrl-D to a DELETE_PARAGRAPH function, or not, as a part of user-set key bindings (or map some other key combination).  While I suppose it's possible to support this requirement by adding and removing a key event handler (one per key?), the InputMap provides a uniform and a rather convenient API.

Similarly, the application requirements might call for runtime unmapping of user bindings, in which case we want an easy API to undo the change and revert back to the default functionality.  Sure, we can juggle the event handlers, but again, the InputMap provides a nice API for that.

Having said all that, I am not particularly against adding prioritization scheme to every event handler (I just think it is unnecessary, but I trust you will provide a good example shortly).

Thank you
-andy

From: openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of Michael Strauß <michaelstrau2 at gmail.com>
Date: Tuesday, May 7, 2024 at 01:44
To:
Cc: openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
Subject: Re: Proposal: Public InputMap (v2)
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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240507/0618b699/attachment-0001.htm>