[External] : Re: Key binding customization proposal

[Andy Goryachev]

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.hendrikx at gmail.com>
Date: Wednesday, November 8, 2023 at 07:58
To: Andy Goryachev <andy.goryachev at oracle.com>, openjfx-dev at openjdk.org <openjfx-dev at 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

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