Key binding customization proposal

Andy Goryachev andy.goryachev at oracle.com
Mon Nov 6 19:54:25 UTC 2023


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

I believe these two requirements are too valuable.  I would object to your proposal because it explicitly provides no support for these two features.

There are more objections, but I think these are enough to disqualify this proposal.

What do you think?  And, more importantly, what do other people - including application developers - think?

Thank you
-andy




From: openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of John Hendrikx <john.hendrikx at gmail.com>
Date: Sunday, November 5, 2023 at 18:07
To: openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
Subject: Key binding customization proposal

This is an extension that builds on top of the Behavior API proposal (see Public Behavior API proposal thread).

Summary:

Provide an opportunity to customize key bindings during construction time of standard behaviors, without exposing the internal InputMaps. The API is constructed in such a way to not block later enhancements to allow InputMaps to be shared or made immutable.

Goals:


  *   Provide API to customize key bindings provided by default behaviors
  *   Provide a public class KeyBinding which is lighter weight, and immutable
  *   Integrate with Behavior proposal
  *   Keep internal details of InputMap implementation hidden (it is too complex, and consumes far too much resources)

See the full proposal here: https://gist.github.com/hjohn/e432f17452ff13511820487e3602b847

--John

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


More information about the openjfx-dev mailing list