Add ability to search the Input gesture dialog by keystroke

[Qchristensen]

Is your feature request related to a problem? Please describe.

If a user wants to change a gesture because of a conflict, they might know the gesture but not the command itself (or they might be aware of the command, but not what it is called in the dialog, as in #10301

Describe the solution you'd like

The ability to enter either the command name OR the keystroke in the Input gestures dialog filter edit.

Describe alternatives you've considered

Additional context

[JulienCochuyt]

@Qchristensen, I'm currently polishing a prototype fix for both #3605 and #3848.
I'll try to implement your requested feature in it and see how it fits.

[JulienCochuyt]

I see a few alternative approaches here:

1. Make the search field search among gesture labels too (as originally requested)

This would produce the most numerous results, even a huge number of them for the first typed characters.
The current filtering has some performance issues which would be worsen.
I'm afraid it could be tedious to write a gesture label just right for most beginners.

2. Switch to filtering by gesture labels as soon as colon (":") and plus ("+") are in the filter string

This would trigger splitting the filter string by component and allow to differentiate eg. gestures implying the letter "c" from gestures implying the control key.

3. Add a "Search gesture" button

When activated, this button would prompt to a gesture to be performed and locate the first (or all) mapped script.
This is not as flexible search-wise, but would IMHO be the most straightforward for end users.

What do you think?

[Qchristensen]

Good points, the filter is already quite slow at updating the treeview, so I would be wary of introducing anything which made it slower. I also was thinking primarily of fairly "simple" to articulate commands like "NVDA+b" which can really only be written a few ways - but what of commands which use Braille display rockers, or touch gestures. Perhaps a button to search by gesture, which, when invoked, takes the next thing you input as the gesture to search for (just as it does when entering a new gesture) - that would enable the function to interpret the gesture and use consistent search terms internally, and also not put extra burden on the filter edit.

[JulienCochuyt]

@Qchristensen Where do you think we should place this button and how do you think we should label it?
For the label, I'd propose "Search a gesture", followed when pressed by the usual prompt.
Regarding its position, it would visually fit nicely left to the current filter field, but I guess for blind use it would better fit one tab index before it.
What do you think?

Regarding the current filtering that makes NVDA lag, please see PR #10307: It does not speed it up in essence, but NVDA behaves much smoother when speed typing a filter term.

[XLTechie]

On Tue, 1 Oct 2019, Julien Cochuyt wrote: @Qchristensen Where do you think we should place this button and how do you think we should label it? For the label, I'd propose "Search a gesture", followed when pressed by the usual prompt.

May I suggest "Search by gesture" would be more clear about what is going to happen?

[JulienCochuyt]

Where do you think we should place this button and how do you think we should label it? For the label, I'd propose "Search a gesture", followed when pressed by the usual prompt.

May I suggest "Search by gesture" would be more clear about what is going to happen?

I was afraid that if the button was too close from the filter field, this phrasing would imply that the gesture should be expressed there.
Anyway, @XLTechie, what do you think regarding where to place the button?

[Qchristensen]

I agree with the wording "Search by gesture", or possibly "Gesture search" which is slightly shorter. I was going to suggest if you put it before the filter field / label, it logically separates it slightly more than if we put it after, where, as indicated, it could easily be confused that you need to type the gesture into the field.

[JulienCochuyt]

@Qchristensen alright, less aesthetic, but probably more ergonomic.
If we all agree here I'll try to integrate this feature in my prototype fix for #3605 and #3848.

[XLTechie]

Julien Cochuyt wrote:

I was afraid that if the button was too close from the filter field, this phrasing would imply that the gesture should be expressed there.

Hmm, I can see that problem.

Anyway, @XLTechie, what do you think regarding where to place the button?

If it is a button rather than a field, and I don't think it can be a field, I think the confusion problem will be amplified if it is after the Filter By field. That only leaves before it.

[hdzrvcc0X74]

Hi @Qchristensen, @XLTechie and @JulienCochuyt!
I was working on some translations for NVDA and needed to compare strings. I had to find a specific string related to the message about turning typed character echo on and off in a list of about 3000 strings. Since I have the Typing Settings add-on, I couldn't find it immediately because it has its own string for that shortcut. So, while input help is enabled and the Typing Settings add-on is installed, pressing NVDA+2, the string reads "Switches between the available speak characters modes." I needed the other, original NVDA string to find it in the list of about 3000 strings. I had to disable the Typing Settings add-on and then perform the same procedure. This time, when I enabled input help and pressed the NVDA+2 shortcut, the string read "Toggles on and off the speaking of typed characters." That's exactly what I needed, and after about three minutes of fiddling around, I found it.
I believe that this feature would be very good and useful to many, and at the same time, it would reduce the need for third-party solutions.
I think the best solution would be precisely the "Search by Gesture" button, which, when activated, records the first key pressed or key combination. After that, a list of categories and actions associated with that gesture should be displayed. This button should work the same way as the button for adding a new gesture, as it would record the first key or keys pressed. What could also be good is adding the option, just like when adding a gesture, to display a dialog box asking whether we are looking for the shortcut set for the desktop keyboard layout or the laptop layout, or for all layouts.
If you have any additional questions, feel free to ask.