Dear Martin: I think the limitation of the current design were expressly listed in the Summary.
The Eclipse example was a use case example, we are not saying we will provide any kind of UI or the framework to synchronize the behavior between multiple instances. This proposal does, however, make it possible. The question of priority was addressed in my recent response to John’s email (addEventFilter) and I feel it’s not relevant to the problem at hand, which is to provide customization of key bindings, including at run time. The “feature request” (common keys) in the second part of your message is a separate and possibly valid concern, but it’s a separate issue. Perhaps you could start a new thread listing some (all?) examples? I don’t think we have any existing documentation of the key bindings, so here we go: https://github.com/andy-goryachev-oracle/jfx/tree/8314906.behavior.test/doc-files/behavior The question I have is: is there anything in this proposal that makes it impossible to do something, and if so, what is it specifically? Is there a concrete design you would like to propose that might be better? Thank you -andy From: openjfx-dev <openjfx-dev-r...@openjdk.org> on behalf of Martin Fox <mar...@martinfox.com> Date: Wednesday, October 11, 2023 at 10:27 To: John Hendrikx <john.hendr...@gmail.com> Cc: openjfx-dev@openjdk.org <openjfx-dev@openjdk.org> Subject: Re: [Request for Comments] Behavior / InputMap On Oct 11, 2023, at 1:03 AM, John Hendrikx <john.hendr...@gmail.com> wrote: After reading John's message I realize that the InputMap proposal doesn’t list the limitations of the current design. It seems to be addressing some of the sequencing issues John mentions but doesn’t state outright that it’s doing so or why. I would set aside the proposal and focus on writing a problem statement document first. A system to remap keys can then be left squarely in the realm of user space, and much nicer solutions can be build by users than whatever JavaFX will provide out of the box. Seconded. Whatever Eclipse is doing to implement their key binding interface is deep and complex and there’s no way JavaFX could craft a solution Eclipse would use. I think that will be true for most apps that allow user customizable key bindings. And I’m pretty sure that when the user customizes a key binding Eclipse is not tracking down all of the affected controls and updating their per-instance key binding maps. Those maps have to be centralized and shared in some manner. So in short, what I think this should be about is: - Ensure user event handlers have priority over behavior/inputmap added ones - Ensure all behavior actions are available as methods on controls I have another recommendation (which may be more of a feature request). There should be a centralized way of mapping common keys to actions to ensure a consistent vocabulary across the user interface. As an example, on many controls Shift + up arrow should map to something like “moveUpAndExtendTheSelection”. There are a lot of these standardized bindings, some of them are platform specific, and it’s a really tall order to expect all of the individual control classes to get this right. On macOS there are two primary means of mapping a key event to an action and both are global. This means most of these mappings happen outside the individual controls and that the mappings are consistent across controls. This also addresses part of what John mentioned above; to make this work controls have to make their actions visible through callable methods. Phrased as problem statement: currently individual control classes need to separately implement a large set of standardized keyboard bindings. This is a maintenance and testing issue. - Ensure that if a key is handled by the control, that it is ONLY consumed when it actually triggers an action (navigation keys get consumed regardless, even if no focus change results, that's wrong). As I recall this is an issue with the traversal engine which is a maybe a separate topic (?) Was a bug ever entered on this? Martin On 10/10/2023 19:54, Andy Goryachev wrote: Re-sending with a smaller image (256kb limit, really?). From: Andy Goryachev <andy.goryac...@oracle.com><mailto:andy.goryac...@oracle.com> Date: Tuesday, October 10, 2023 at 10:49 To: Michael Strauß <michaelstr...@gmail.com><mailto:michaelstr...@gmail.com> Cc: openjfx-dev@openjdk.org<mailto:openjfx-dev@openjdk.org> <openjfx-dev@openjdk.org><mailto:openjfx-dev@openjdk.org> Subject: Re: [Request for Comments] Behavior / InputMap Dear Michael: Here is a use case for (re-)mapping by the user at runtime: <image002.jpg> (key mappings UI in Eclipse). I can think of several other cases (mentioned in the proposal, I think) so I think we can put the concept of immutable or global InputMap to rest. Whether the InputMap contains the reference to its control or not is a minor implementation detail, I think. -andy From: openjfx-dev <openjfx-dev-r...@openjdk.org><mailto:openjfx-dev-r...@openjdk.org> on behalf of Michael Strauß <michaelstr...@gmail.com><mailto:michaelstr...@gmail.com> Date: Tuesday, October 10, 2023 at 10:36 To: Cc: openjfx-dev@openjdk.org<mailto:openjfx-dev@openjdk.org> <openjfx-dev@openjdk.org><mailto:openjfx-dev@openjdk.org> Subject: Re: [Request for Comments] Behavior / InputMap > Yes, one of the features the new design provides is ability to modify key > mappings by the user at runtime. So yes, not only it needs to be mutable, > but it also adds some APIs for exactly that. > I struggle to see a use case for this feature. I can imagine that there might be some use cases that call for customized input mappings, but why would this translate to a _mutable_ input map? That's quite a departure from the way other parts of JavaFX work. For example, skins are also immutable. If you want to have a different skin for a control, you don't somehow modify the existing skin instance; instead, you'd create a new skin class (or -- somehow -- extend an existing skin class), and then install that new skin on your control. An input map shouldn't bind input events directly to instance methods of a particular control instance. It should define the mapping of events to methods symbolically: Instead of mapping Event => instance.method(), it should map Event => Control::method. The input map could then be stateless and immutable, and can be set on any control instance. If you want to change the mappings, just set a different input map instance. There's no need that an input map would retain a reference to any particular control, since the control reference can be passed into the input map just as easily.
