Dear John:

1.       Runtime modification of key bindings on a per control basis
Before I reply further, where is the use case for this?

A very good question, thank you for asking.  You might scroll back to find it 
answered a couple of times during the discussion, but I think it’s worth 
exploring it further.

There is a number of use cases for runtime modifications:

- there might be a requirement to switch between vim/emacs/etc. key mapping
- there might be a requirement to customize the mapping per user configuration 
(see the Eclipse “Keys” UI that I’ve shown before)
- there are many apps (AquaFold Data Studio, for one I remember) which allows 
for customization of key bindings

>From the API perspective, this functionality should be possible.

Hope this answers your question.
-andy



From: John Hendrikx <john.hendr...@gmail.com>
Date: Wednesday, November 8, 2023 at 07:58
To: Andy Goryachev <andy.goryac...@oracle.com>, openjfx-dev@openjdk.org 
<openjfx-dev@openjdk.org>
Subject: [External] : Re: Key binding customization proposal


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:


  1.  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

  1.  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

Reply via email to