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-r...@openjdk.org> on behalf of John Hendrikx <john.hendr...@gmail.com> Date: Sunday, November 5, 2023 at 18:07 To: openjfx-dev@openjdk.org <openjfx-dev@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
