Key binding customization proposal

[John Hendrikx]

On 06/11/2023 20:54, Andy Goryachev wrote:
>
> Dear John:
>
> Thank you again for submitting a separate KeyBinding proposal.  
> Ignoring my objection for its sibling, I just wanted to point to these 
> two items in Goals and Non-Goals:
>
>   * Keep internal details of InputMap implementation hidden (it is too
>     complex, and consumes far too much resources)
>
> I object to this on two fronts:
>
> 1. by trying to go around the InputMap, something that many developers 
> find easy to understand, you invented a bunch of weird things like 
> InputContext, Actions (not those Actions that we are used to!), and 
> States.  Why? What is the problem?  How is what you propose is NOT 
> “too complex” but an InputMap is?
>
> 2. You still need to add a listeners on each control instance, right?
>
> But the main objection comes from
>
>   * Runtime modification of key bindings on a per control basis
>
Before I reply further, where is the use case for this? I don't see it 
in any of the earlier linked tickets.  All those tickets want Behaviors 
opened up to ease Skin subclassing, but that's not addressed in any way.

https://bugs.openjdk.org/browse/JDK-8092211

https://bugs.openjdk.org/browse/JDK-8091189

https://bugs.openjdk.org/browse/JDK-8186137

Especially runtime modification of default key bindings (ie. ones like 
Ctrl-A, cut, copy, paste, cursor key based navigation, etc) seems 
entirely out of scope to be able to modify at runtime as that would be 
way too confusing for users.  I'd expect these at most to be modified 
once (immediately after control construction, or simply as part of a 
Behavior) when preferences change or the application is restarted.

Note that I also don't think the key bindings should serve as an 
alternative mechanism to define keys tied to custom functions (ie, 
functions not supplied by FX).  That's what KeyEvents are for. The 
mapping system allows changing of internal key choices, but how these 
are used exactly (react on pressed or released, on hold duration, etc) 
is NOT configurable and so should not be seen as an alternative for 
using KeyEvents.

--John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20231108/c549429f/attachment-0001.htm>