Dear Michael: Thank you for specific questions!
> "switch between vim/emacs/etc. key mappings"? Maybe you can give a specific > example. Vim/emacs might be a bad example, as they use key sequences. Key sequences are not a part of this proposal (but it is possible to implement with the help of the proposed API). One example is a user preference for Go-To-Line function typical in text editors. In jEdit on Mac it’s ⌘E, while in Eclipse it’s ⌘G. The user might strongly prefer to have one or the other, so an application requirement might include redefining one or more keys. Since it’s a user preference, it has to be done at runtime. 1. The way I understand it, the only thing a public InputMap API would enable developers to do would be to change key mappings of existing control functionality. For example, I could re-map the left arrow to invoke the "moveRight" function, or I could re-map ctrl+A to "copy" text, instead of "select all" text. But why would I want to do that? These are default mappings for a reason. Is there any example in which such a re-mapping would potentially be useful? The public API should *enable* the possibility, even if the core set of controls do not require it. I It is not the case of whether you want to remap ctrl-A to COPY, but a case when an application developer has a requirement to remap something (command-E to command-G). You even hint at such a requirement when talking about navigating camel case words. 2. We seem to be talking about text a lot. Is there any specific example beyond TextInputControl that would benefit from this feature? Maybe this should be an extension for TIC, and not for the control architecture as a whole? Some controls do not need an input map, some do. Some controls may not benefit from key mapping, but others do. I focused on TIC because that’s the area I am currently focused on, but perhaps Tree/Table view could be another case where custom key mapping might be useful. 3. I have two examples that are not possible in JavaFX right now (at last not out of the box): ... The proposed API doesn't enable me to implement those features, does it? It does, it was specifically designed with these requirements in mind. For example, for Scroll through text on a word-by-word basis (look for: "Use CamelHump words" You’d define a custom function tags for NEXT_CAMEL_HUMP_STOP/PREVIOS_CAMEL_HUMP_STOP and implement the functions (get caret position or selection range from the control, computing the next/previos stop by looking at the text, and setting the caret to the new position), and remapping the RIGHT/LEFT keys to the new function. If everything you need is provided to you by the control’s public API, you don’t even have to touch the default skin or its behavior. Same applies for "Home moves caret to first non-whitespace character". Depending on what you want, the custom function could consult the preference setting, if any, and compute the new caret position entirely from information available via public APIs in the control. A smarter control might even provide these function variants as part of its default behavior, for example MOVE_LINE_START/MOVE_FIRST_NON_WHITESPACE_CHAR or something like that. It’s probably my fault that it is not immediately apparent from the proposal that these use cases are supported by design. Thanks -andy From: openjfx-dev <openjfx-dev-r...@openjdk.org> on behalf of Michael Strauß <michaelstr...@gmail.com> Date: Wednesday, November 8, 2023 at 11:24 To: openjfx-dev@openjdk.org <openjfx-dev@openjdk.org> Subject: Re: [External] : Re: Key binding customization proposal Hi Andy! > 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 Maybe we should pull on this string a little bit more. It's still not clear to me what the requirements actually are. What is meant by "switch between vim/emacs/etc. key mappings"? Maybe you can give a specific example. 1. The way I understand it, the only thing a public InputMap API would enable developers to do would be to change key mappings of existing control functionality. For example, I could re-map the left arrow to invoke the "moveRight" function, or I could re-map ctrl+A to "copy" text, instead of "select all" text. But why would I want to do that? These are default mappings for a reason. Is there any example in which such a re-mapping would potentially be useful? 2. We seem to be talking about text a lot. Is there any specific example beyond TextInputControl that would benefit from this feature? Maybe this should be an extension for TIC, and not for the control architecture as a whole? 3. I have two examples that are not possible in JavaFX right now (at last not out of the box): - In IntelliJ, there's an option that toggles the way I can scroll through text on a word-by-word basis (look for: "Use CamelHump words"). If toggled, I can ctrl-arrow left or right, and the caret will be placed either at the beginning of the next or previous word boundary, or alternatively at the beginning of the next or previous case change within a word (the "CamelHump"). - Also in IntelliJ, there's an option for "Home moves caret to first non-whitespace character". The alterative is that Home moves the caret to the beginning of the line. The proposed API doesn't enable me to implement those features, does it? This leads me to think that what we really need is a way to customize the "behavior" (whatever this ends up being) of a control more so than its default key mappings.
