[Request for Comments] Behavior / InputMap

[John Hendrikx]

I'm sorry, but that providing an arbitrary key mapping system seems 
completely out of scope and not something that JavaFX should concern 
itself with.  It's much too high level, when the key mappings involved 
should only be for actions that the control can provide on its own.

I think the problem we should be solving is that JavaFX control 
behaviors shouldn't be first in line when it comes to consuming events 
(which currently is only the case due to event handlers being added at 
the earliest possible opportunity, and event handlers being called in 
order).  If something as trivial as:

        control.addEventHandler(KeyEvent.KEY_PRESSED, e -> {
               if (e.getCode() == KeyCode.LEFT) {
                     e.consume();  // stop default behavior
               }
        });

... actually worked, then there is much less need to redefine/disable 
behavior key mappings, and no need for a secondary system that deals 
with mappings (the first system, event handlers, can simply be used for 
this).  If user event handlers had priority over behavior ones, then 
everything you want can be achieved with the above, including:

- Stopping default behavior
- Triggering different behavior (just call something on control, of 
course, make sure all behavior actions are available on the control in 
the first place)
- Remapping (a combination of the above two)
- Adding an alternative key for the same behavior

A system to remap keys can then be left squarely in the realm of user 
space, and much nicer solutions can be build by users than whatever 
JavaFX will provide out of the box.

Changes to the Behavior system can then focus on replacing complete 
behaviors (including their input map) and being able to use these by 
default for a certain subset of controls (like -fx-skin provide in CSS), 
as this is something users currently can't do.

So in short, what I think this should be about is:

- Ensure user event handlers have priority over behavior/inputmap added ones
- Ensure all behavior actions are available as methods on controls
- Ensure that if a key is handled by the control, that it is ONLY 
consumed when it actually triggers an action (navigation keys get 
consumed regardless, even if no focus change results, that's wrong).

Future:

- Make behaviors public and allow Behaviors to be replaced with 
-fx-behavior type CSS syntax / control.setBehavior calls

--John


The focus should be on being able to modify standard behavior of 
controls (arrow-left, enter, ctrl-shift-right, etc.), specifically also 
to be able to disable these when undesired, and, on top of that, that 
they bubble up when NOT used even when they are configured (focus 
navigation keys currently are always consumed, whether they actually do 
something or not -- that's a big issue). The other focus should be on 
providing an alternative behavior (or at least mappings) for all 
controls of a certain type -- I don't see the need for adding a mapping 
to a specific control, that's already covered with event handlers; the 
problem is mostly that behaviors currently steal certain events before 
the user can get at them.

Custom behaviors can then be constructed that provide more things that 
may need mapping.  I'd expect those however to be limited in scope to 
what the control offers, certainly not an arbitrary key/action mapping 
system (that wouldn't even work, as most of these would be in the scope 
of several controls or be global). This kind of functionality is much 
better provided by event handlers at the correct level for a group of 
controls, and I wouldn't expect to find such an eloborate system 
incorporated in behaviors.

In fact, thinking about all of this a bit more,


On 10/10/2023 19:54, Andy Goryachev wrote:

> Re-sending with a smaller image (256kb limit, really?).
>
> *From: *Andy Goryachev <andy.goryachev at oracle.com>
> *Date: *Tuesday, October 10, 2023 at 10:49
> *To: *Michael Strauß <michaelstrau2 at gmail.com>
> *Cc: *openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
> *Subject: *Re: [Request for Comments] Behavior / InputMap
>
> Dear Michael:
>
> Here is a use case for (re-)mapping by the user at runtime:
>
> (key mappings UI in Eclipse).
>
> I can think of several other cases (mentioned in the proposal, I 
> think) so I think we can put the concept of immutable or global 
> InputMap to rest.
>
> Whether the InputMap contains the reference to its control or not is a 
> minor implementation detail, I think.
>
> -andy
>
> *From: *openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of 
> Michael Strauß <michaelstrau2 at gmail.com>
> *Date: *Tuesday, October 10, 2023 at 10:36
> *To: *
> *Cc: *openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
> *Subject: *Re: [Request for Comments] Behavior / InputMap
>
> > Yes, one of the features the new design provides is ability to modify 
> key mappings by the user at runtime.  So yes, not only it needs to be 
> mutable, but it also adds some APIs for exactly that.
> >
>
> I struggle to see a use case for this feature. I can imagine that
> there might be some use cases that call for customized input mappings,
> but why would this translate to a _mutable_ input map? That's quite a
> departure from the way other parts of JavaFX work.
>
> For example, skins are also immutable. If you want to have a different
> skin for a control, you don't somehow modify the existing skin
> instance; instead, you'd create a new skin class (or -- somehow --
> extend an existing skin class), and then install that new skin on your
> control.
>
> An input map shouldn't bind input events directly to instance methods
> of a particular control instance. It should define the mapping of
> events to methods symbolically:
>
> Instead of mapping Event => instance.method(), it should map Event =>
> Control::method. The input map could then be stateless and immutable,
> and can be set on any control instance. If you want to change the
> mappings, just set a different input map instance. There's no need
> that an input map would retain a reference to any particular control,
> since the control reference can be passed into the input map just as
> easily.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20231011/85e04f95/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 104433 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20231011/85e04f95/image002-0001.jpg>