Opened 3 years ago

Closed 12 months ago

Last modified 12 months ago

#1532 closed enhancement (fixed)

GUI For "Remapping Key Assignments and Other Input Gestures"

Reported by: ateu Owned by: jteh
Priority: minor Milestone: 2013.3
Component: GUI Version: master
Keywords: Cc:
Operating system: Blocked by:
Blocking:
Changes document entry (for developers): New Features: - There is now an Input Gestures dialog to allow simpler customization of the input gestures (such as keys on the keyboard) for NVDA commands. (#1532) Changes for Developers: - You can specify the category to be displayed to the user for scripts using the scriptCategory attribute on ScriptableObject classes and the category attribute on script methods. See the documentation for baseObject.ScriptableObject for more details.

Description

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.

Change History (23)

comment:1 Changed 3 years ago by jteh

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.

comment:2 Changed 18 months ago by camlorn

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.

comment:3 Changed 18 months ago by jteh

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.

comment:4 Changed 18 months ago by camlorn

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.

comment:5 Changed 17 months ago by nvdakor

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.

comment:6 Changed 13 months ago by jteh

  • Owner set to jteh
  • Status changed from new to accepted

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.

comment:7 Changed 13 months ago by beqa

hi all.

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

activate python console: kb:control+z+nvda

comment:8 follow-up: Changed 13 months ago by nvdakor

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.

comment:9 in reply to: ↑ 8 Changed 13 months ago by jteh

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.

comment:10 Changed 13 months ago by Michael Curran <mick@nvaccess.org>

In 5281be32c51ae852667e82ee5a7864b5c7a1280b:

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

comment:11 Changed 13 months ago by Michael Curran <mick@nvaccess.org>

In 8d076275085b82a7847d167c62c30de2f9bc4395:

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

comment:12 Changed 13 months ago by Michael Curran <mick@nvaccess.org>

In c9e945183c38f9ad2606ba4e40e4c29e1c49414d:

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

comment:13 Changed 13 months ago by jteh

  • Milestone set to next

comment:14 Changed 13 months ago by James Teh <jamie@nvaccess.org>

  • Status changed from accepted to incubating

In d4e14a86bff9b7dc93f85d36d903898d3cc3d126:

Merge branch 't1532' into next

Incubates #1532.

comment:15 Changed 12 months ago by James Teh <jamie@nvaccess.org>

In 2633f7e1936631a42fa83e26fa9678dd1f882446:

Merge branch 't1532' into next

Incubates #1532.

comment:16 follow-up: Changed 12 months ago by beqa

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.

comment:17 in reply to: ↑ 16 Changed 12 months ago by jteh

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.

comment:18 Changed 12 months ago by MHameed

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.

Last edited 12 months ago by MHameed (previous) (diff)

comment:19 Changed 12 months ago by jteh

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.

comment:20 Changed 12 months ago by jteh

  • Changes document entry (for developers) modified (diff)

comment:21 Changed 12 months ago by James Teh <jamie@nvaccess.org>

  • Resolution set to fixed
  • Status changed from incubating to closed

In 5cac9605aa68553359700273fb9cb8bed0fce826:

Merge branch 't1532'

Fixes #1532.

comment:22 Changed 12 months ago by jteh

  • Milestone changed from next to 2013.3

comment:23 Changed 12 months ago by leonarddr

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?

Note: See TracTickets for help on using tickets.