-
-
Notifications
You must be signed in to change notification settings - Fork 626
-
-
Notifications
You must be signed in to change notification settings - Fork 626
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add ability to search the Input gesture dialog by keystroke #10302
Comments
@Qchristensen, I'm currently polishing a prototype fix for both #3605 and #3848. |
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. 2. Switch to filtering by gesture labels as soon as colon ("
|
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. |
@Qchristensen Where do you think we should place this button and how do you think we should label it? 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. |
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?
|
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. |
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. |
@Qchristensen alright, less aesthetic, but probably more ergonomic. |
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.
|
Hi @Qchristensen, @XLTechie and @JulienCochuyt! |
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
The text was updated successfully, but these errors were encountered: