GUI For "Remapping Key Assignments and Other Input Gestures"

[nvaccessAuto]

Reported by ateu on 2011-05-30 16:18
Hello
Now nvda allows to do this changes manually, I think you have all the tools and you can easily create a menu iten for this option.
So all the users will enjoy it.

[nvaccessAuto]

Comment 1 by jteh on 2011-05-30 21:19
Unfortunately, this is not at all easy, as it needs to search for commands in all currently loaded modules and then determine which of those are matched by user and locale gesture maps. There is currently no efficient way to do this. Aside from this, command names and module names aren't currently user friendly or translatable, which needs to be done before a GUI can be considered.

Good patches are of course welcome.

[nvaccessAuto]

Comment 2 by camlorn on 2013-03-31 02:49
I saw that this came up again recently, and have been considering opening a ticket for this for some time. Both of my computers, both my Windows laptop and my Macbook with bootcamp have keys that do not work properly, because the keyboard fails to recognize the keystroke combination altogether, so I'm going to assume that this isn't as rare as we would hope. The current option for modifying keystrokes is very, very technical; while I can complete it, I doubt someone newer to NVDA could. Also, it requires that you be able to obtain the name of the key, one way or another; the user guide only offers one option unless I'm missing a section: be able to actually press the key in the first place. I am lucky enough to have an external keyboard, but again, I imagine that many do not.
Even if this ignores add-ons, there really needs to be a way to do this without going through the cumbersome steps that the user guide says one must take. I am going to leave implementation suggestions to those qualified to actually usefully talk about them, as I have no idea how NVDA handles this, but it really does need to happen at some point. There is the option of maintaining a complete list of nvda keystrokes with names, but this seems unwise, at least to me.

[nvaccessAuto]

Comment 3 by jteh on 2013-04-01 22:28
The fact that this needs to be done is not in question. Unfortunately, it's extremely difficult to implement and would probably require weeks of implementation time that we don't currently have given other priorities.

I assume you mean you need to be able to press the key to get the name of the command you want to remap? You don't need the name of the key itself.

[nvaccessAuto]

Comment 4 by camlorn on 2013-04-02 02:39
Yes, that's what I meant. My estimate was not weeks, to be quite honest. I saw the first comment and assume that this was just sort of considered to be not worth it. I didn't realize it would take that long.

[nvaccessAuto]

Comment 5 by nvdakor on 2013-05-11 09:12
Hi,
I and Beqa are trying to come up with a parsing algorithm (the first step to solving this ticket). Currently, Beqa is investigating how Orca does this.

[nvaccessAuto]

Comment 6 by jteh on 2013-08-22 12:55
I started some work in the t1532 branch. This is far from complete; even after several hours of solid work, I haven't even thought about coding the GUI yet.

[nvaccessAuto]

Comment 7 by beqa on 2013-08-27 03:27
hi all.

i found bug in latest revision
modifier nvda is written in last position e.g

activate python console: kb:control+z+nvda

[nvaccessAuto]

Comment 8 by nvdakor on 2013-08-29 18:10
Hi,
A few additional findings:

• Gesture display: I can confirm Beqa's observation that NvDA modifier is written last.
• Adding a gesture: Two issues:
  1. After adding a gesture, gestures list shows NvDA modifier before any other keys used for creating that gesture e.g. Shift+B+NvDA for existing gesture versus NvDA+Shift+B for newly created gesture. When the users presses OK and the user returns to this screen, the newly added gesture is displayed just like others, with NvDA modifier key placed last.
  2. When adding a gesture to a script and if you know that the gesture you're adding has already been defined (i.e. when adding NvDA+Shift+B to read foreground script but you know that it has been defined for reading battery level), NvDA just "accepts" the gesture - doesn't give a warning message.
• Feature suggestion: I think it'd be great if one can actually choose the keyboard layout for a particular gesture when adding it.
• Request 2: Might be out of scope, but Beqa and I would like to see more groups of gestures represented, including those used in appModules such as Powerpnt, Poedit and so on.
  Thanks.

[nvaccessAuto]

Comment 9 by jteh (in reply to comment 8) on 2013-08-29 21:59
Replying to nvdakor:

• Gesture display: I can confirm Beqa's observation that NvDA modifier is written last.

I'm aware of this. It's very difficult to fix, but obviously needs to be fixed before merge. It's probably the one issue that will very seriously delay this being merged.

1. When adding a gesture to a script and if you know that the gesture you're adding has already been defined (i.e. when adding NvDA+Shift+B to read foreground script but you know that it has been defined for reading battery level), NvDA just "accepts" the gesture - doesn't give a warning message.

The problem is that you can have the same gesture defined in different contexts; e.g. NVDA+shift+b to read battery level but also NVDA+shift+b in a specific app. We could detect a conflict in the same context, but in different contexts, it technically isn't a conflict. Unfortunately, global plugins are all considered different contexts.

• Feature suggestion: I think it'd be great if one can actually choose the keyboard layout for a particular gesture when adding it.

UI for this would be difficult without biasing the entire dialog to keyboard gestures. Remember, this is for all input sources (braille displays, etc.), not just keyboard.

• Request 2: Might be out of scope, but Beqa and I would like to see more groups of gestures represented, including those used in appModules such as Powerpnt, Poedit and so on.

Only the commands relevant to the focus can be shown. Other app modules might not even be loaded yet. If a particular app has focus when the dialog is activated, those commands will be included. A keyboard shortcut needs to be added to activate the dialog for this reason.

[nvaccessAuto]

Comment 10 by Michael Curran <mick@... on 2013-09-02 06:13
In [5281be3]:

The Input Gestures dialog can be opened with NVDA+control+i. Re #1532

[nvaccessAuto]

Comment 11 by Michael Curran <mick@... on 2013-09-02 06:13
In [8d07627]:

Give all scripts on virtualBuffers a script category (for the input guestures dialog) of 'Browse mode'. Re #1532

[nvaccessAuto]

Comment 12 by Michael Curran <mick@... on 2013-09-02 06:43
In [c9e9451]:

Set the scriptCategory of 'Browse mode' on the cursorManager class rather than the VirtualBuffer class, so that it also includes NVDA-specific text find commands. Re #1532

[nvaccessAuto]

Comment 13 by jteh on 2013-09-09 09:29
Changes:
Milestone changed from None to next

[nvaccessAuto]

Comment 14 by James Teh <jamie@... on 2013-09-09 09:31
In [d4e14a8]:

Merge branch 't1532' into next

Incubates #1532.

Changes:
Added labels: incubating

[nvaccessAuto]

Comment 15 by James Teh <jamie@... on 2013-09-12 07:04
In [2633f7e]:

Merge branch 't1532' into next

Incubates #1532.

[nvaccessAuto]

Comment 16 by beqa on 2013-09-14 07:29
hi all.

maybe this is trivial task but anyway:
if we have two or more modules with similar script_docs it is difficult to determine which gesture we are changing.

so, maybe add a prefix with module or make subcategory depending on this module.

thanks.

[nvaccessAuto]

Comment 17 by jteh (in reply to comment 16) on 2013-09-14 10:11
Replying to beqa:

if we have two or more modules with similar script_docs it is difficult to determine which gesture we are changing.

Can you provide an example?

so, maybe add a prefix with module or make subcategory depending on this module.

I think subcategories would be cumbersome and they're also difficult to implement. Depending on the cases you're considering, the problematic commands should perhaps be moved into separate categories.

[nvaccessAuto]

Comment 18 by MHameed on 2013-09-15 23:53
What I had in mind is that when the user installs a new addon (appModules), he should be able to easely locate the shortcuts that were added by the given addon, and reassign them.
This is true for when the app is open.

For the globalPlugin case, maybe the shortcuts can be categorized by globalPlugin too.
That should mean less admin for us on the addon list, the addon author can just note what other addon his shortcuts clashes with, and this will prompt the user to go and reassign them if they have both addons installed.

This also applicable if a particular language keyboard layout doesn't support the assigned keys.

[nvaccessAuto]

Comment 19 by jteh on 2013-09-16 02:32
Imo, add-ons should integrate right into NVDA as far as the user is concerned. Perhaps the add-on wants to add an object navigation or a browse mode command. Forcing them to be in a separate category makes them look very different and kills tight integration.

Any script can choose the category it is assigned to. On individual scripts, you use the category attribute. To set the default category for a class, you use the scriptCategory attribute on the class. This gives the add-on author the choice. Most existing script categories have SCRCAT_* constants in appropriate modules so they can be used by others if desired.

[nvaccessAuto]

Comment 21 by James Teh <jamie@... on 2013-10-02 03:30
In [5cac960]:

Merge branch 't1532'

Fixes #1532.

Changes:
Removed labels: incubating
State: closed

[nvaccessAuto]

Comment 22 by jteh on 2013-10-02 03:31
Changes:
Milestone changed from next to 2013.3

[nvaccessAuto]

Comment 23 by leonarddr on 2013-10-02 09:51
When adding a gesture, a popup menu opens to select which keyboard layout to use for the gesture. From that moment on, there seems to be no way to cancel other than brutely pressing alt+f4, or select one of the layouts and delete the keystroke afterwards. Could an "abort" option be added to the popup menu?