[External] : Re: Key binding customization proposal

[John Hendrikx]

On 08/11/2023 21:18, Andy Goryachev wrote:
>
> 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.
>
That's not a function offered by text controls at all.  That's a short 
cut for a menu function that will pop-up a dialog asking for a line 
number (Ctrl + L in Eclipse).

Standard behavior is everything that's standard about a control's 
behavior that people come to expect when using their platform of 
choice.  Any text field will offer defaults like:

left: move cursor one character to the left
control+left: move cursor one word to the left
home: move cursor to start of line
ctrl+home: move cursor to start of text
ctrl+x/c/v: cut/copy/paste

etcetera.

What you are proposing here is about providing high level short-cuts 
which IMHO is squarely in the domain of the application developer, or 
some 3rd party.  FX should only care about offering ways to change the 
implicit standard key bindings that you use without even thinking about.

Basically, if it isn't a function offered directly by the control, and 
handled directly by the control, then it's the application that should 
be handling it.  And they can handle this already by assigning such a 
short cut to a menu, or by installing global/local event handlers.

What they CAN'T do right now is:

- Disabling one of those implicit key bindings because you want to use 
it for something else (ie, application managed)
- Remapping an implicit key binding to a different key

Both of these are a rare occurence, as this would immediately cause 
usability issue as you'd be deviating from standard control behavior, 
but it may perhaps be useful in some very rare cases. This is why I 
think it's fine to have to do a bit more work to achieve this (ie. 
subclass a Behavior).

> 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.
>
How are you going to configure all the intricacies here?  When should a 
key trigger, on PRESSED, RELEASED, on both?  What about when I hold it 
down for more than 0.7 seconds?  That's not something I made up, but in 
use in actual code:

       long heldTime = System.currentTimeMillis() - keyPressedStartTime;

       if (keyPressedCode == event.getCode() && heldTime >= 700) {
         handleLongPressKeyEvent(event);
       }

...there are so many cases, and there is no way this can all be captured 
with a simple "A to B" input map.

It also still ignores the fact that some of these standard keys react 
differently already.  Take SPACE for Button for example; it doesn't fire 
on PRESSED, it fires on RELEASED.  If I want it to fire immediately (so 
I can do key repeat on Buttons, for some game or something), I already 
need to write a custom function, but without the benefit of being able 
to access ButtonBehavior's internal state, like the "keydown" flag 
(which to be clear is not the same as Control.isArmed()).


> 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.
>
I'm wondering if you tried doing this already: modify a Skin (directly 
in FX repository), removing one of its more complicated bindings, and 
reimplement it. I suspect that there is quite some internal state that 
is unavailable on Control that you'd need to know in order to make it 
feel again like it is part of the control (why else are Behaviors 
stateful) and so it works exactly the same as it did before.

I suspect that without access to all the internals, such a custom 
function will feel like a hotkey, that disregards anything else that's 
going on in the control, and just does its thing whether that's a good 
idea right now or not; it won't feel as an integrated part of the control.

--John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20231110/c819598b/attachment.htm>