Skip to content
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

Warn user when overriding a pre-existing input gesture #3605

Open
nvaccessAuto opened this issue Oct 23, 2013 · 6 comments
Open

Warn user when overriding a pre-existing input gesture #3605

nvaccessAuto opened this issue Oct 23, 2013 · 6 comments
Labels
component/NVDA-GUI enhancement p4 https://github.com/nvaccess/nvda/blob/master/projectDocs/issues/triage.md#priority triaged Has been triaged, issue is waiting for implementation.

Comments

@nvaccessAuto
Copy link

Reported by dgoldfield on 2013-10-23 18:55
When you assign an NVDA function to a hotkey which is already assigned, the user is not warned that this key is currently in use or has been assigned to another function.
Example:

  1. Open the "input gestures" dialog box.
  2. Assign a function to the insert-T hotkey.

Of course, the insert-T hotkey is usually the key to read the title bar. NVDA will allow you to make this choice and will override the current function of insert-T, without first warning the user that this key is in use.
Blocking #4915

@nvaccessAuto
Copy link
Author

Comment 1 by jteh on 2013-10-23 19:31
Commands in NVDA are based on context; many are not global. This presents two issues:

  1. The commands displayed in the Input Gestures dialog are only the commands that apply right now. This cannot (and I'd argue shouldn't) be changed. There could be commands that apply in other cases that you won't be warned about. For example, if you override NVDA+f7 when you aren't in browse mode, you wouldn't see any warning because NVDA+f7 doesn't appear unless you're in browse mode.
  2. You may actually want the same key to be used for two different commands as long as they occur in different contexts. As an example, you might be happy to override NVDA+t with an application specific command. NVDA+t will then behave as normal except in that specific application. I guess this can still be allowed by warning the user but not completely preventing the override.

@bhavyashah
Copy link

Since this issue is a deficiency in an existing NVDA feature, this may be worth assigning a slightly higher priority. Also, related ticket #3848 is marked P3, which may be some reason to assign this similar priority so as to tackle both tickets together whenever that happens in the future. Thoughts? @feerrenrut
P.S. Personally, I am not too sure if I follow why this issue and #3848 need to be coexist as related rather than being covered within the ambit of only one ticket. CC @jcsteh

@feerrenrut
Copy link
Contributor

How I read this issue is that "a user should be warned when overriding some other pre-existing shortcut" to solve the problem of hiding an existing command. Jamie has mentioned that the commands are context sensitive, which we will have to think about when proposing a solution to this problem. There is also #7074 which I think is a duplicate of this issue, it has a couple of user stories written on it which, I think, summarise both tickets.

#3848 is a bug in the GUI, not accurately reflecting the current state of gestures.

@LeonarddeR
Copy link
Collaborator

I guess it would be sufficient if NVDA throws a warning when you are trying to assign a gesture which is already assigned in the current context. This would mean, for example, that assigning nvda+f7 outside browse mode would not throw such a warning, but I'd concider that expected behavior.

@feerrenrut feerrenrut changed the title When using the "input gestures" dialog to assign a function to a hotkey, NVDA allows the user to assign to a hotkey already being used by another function Warn user when overriding a pre-existing input gesture Nov 8, 2017
JulienCochuyt added a commit to accessolutions/nvda that referenced this issue Sep 30, 2019
* Input Gestures dialog doesn't reflect a built-in gesture that was just overridden (nvaccess#3848)
* Warn user when overriding a pre-existing input gesture (nvaccess#3605)
@JulienCochuyt
Copy link
Collaborator

I'm currently working on a fix for #3848 that also incorporates an implementation for this feature (both are quite related).

My current approach follows the easy path as proposed by @LeonarddeR in #3605 (comment) that is to consider only the context of the object that has focus before opening the Input Gesture dialog and the current keyboard layout or braille display.

First of all, in a gesture normalized identifier, let's call

  • "source class" the generic part of the source, ie. "kb" or "br"
  • "source modifier" the specific part of the source, ie. "laptop" or "alva"
  • "specifier" everything after the colon, ie. "nvda+t" or "b1"

Would you validate that two gestures are considered conflicting if and only if their source class and specifier are identical and they both have a non-empty source modifier?
Eg. if the current layout is "laptop", "kb:(laptop):nvda+t" overrides "kb:nvda+t" but does not override "kb(desktop):nvda+t"

JulienCochuyt added a commit to accessolutions/nvda that referenced this issue Oct 1, 2019
, nvaccess#3848)

* Warn user when overriding a pre-existing input gesture (nvaccess#3605)
* Input Gestures dialog doesn't reflect a built-in gesture that was just overridden (nvaccess#3848)
@nvdaes
Copy link
Sponsor Contributor

nvdaes commented Nov 3, 2023

Hello. A user of the spanish community is asking for this feature. Can this be triaged? @Adriani90 @CyrilleB79

@seanbudd seanbudd added p4 https://github.com/nvaccess/nvda/blob/master/projectDocs/issues/triage.md#priority triaged Has been triaged, issue is waiting for implementation. labels Nov 6, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
component/NVDA-GUI enhancement p4 https://github.com/nvaccess/nvda/blob/master/projectDocs/issues/triage.md#priority triaged Has been triaged, issue is waiting for implementation.
Projects
None yet
Development

No branches or pull requests

7 participants