Comment 1 by jteh on 2013-12-03 04:44
I think input capture is a bad solution for this problem. If the add-on code breaks for some reason, it could leave NVDA in a state where it captures all input and the user can't undo this. In fact, they wouldn't even be able to quit, kill or restart NVDA.

A better design I've been considering for a while is to have some way of signalling to NVDA that a particular gesture is a prefix for other gestures. That way, the prefixed gestures could just be bound to scripts like any other. They might be of the form kb:NVDA+shift+r,c.

One question is what should occur if the second gesture is invalid. Right now, we don't report an error if the user presses an unbound NVDA keystroke (e.g. NVDA+y) and this is a similar situation.

Btw, I wonder whether the term prefixed gestures is clearer. Layering suggests one goes on top of the other, which I don't feel is a good fit here.

Comment 2 by nvdakor on 2013-12-03 05:37
Hi,
For errors, I think outputting an error beep should work without sending the key to the OS.
Another question: so if we do decide to use prefix gesture definition syntax. Would that mean the developer should type "comma" when trying to assign a gesture to this key, since comma would be used as the prefix/command separator in your syntax? Or what if the developer had something like:
"kb:nvda+g":"someScript", "kb:nvda+g,h":"scriptHelp"
Would this be seen as ambiguous from input manager's point of view?
Thanks.

Comment 3 by jteh (in reply to comment 2) on 2013-12-03 07:01
Replying to nvdakor:

For errors, I think outputting an error beep should work without sending the key to the OS.

I think that bit will be tricky to implement.

Another question: so if we do decide to use prefix gesture definition syntax. Would that mean the developer should type "comma" when trying to assign a gesture to this key, since comma would be used as the prefix/command separator in your syntax?

Yeah, not sure about that yet. It could be that "," is only treated as a separator if there is more than one.
Actually, perhaps we could just use a space as the separator; i.e. "kb:NVDA+g h".

Or what if the developer had something like:

"kb:nvda+g":"someScript", "kb:nvda+g,h":"scriptHelp"

Isn't that a conflict? The NVDA+g would override in that case.

I imagine bindings would have to define a gesture as a prefixed gesture; e.g. "kb:NVDA+g": "prefixedGesture", "kb:NVDA+g h": "help".

Comment 4 by ABuffEr on 2015-09-26 17:26
Hi all,
I'm working on a local branch, try to implement a first prototype of layered gestures.
I primarily modified baseObject.ScriptableObject class, introducing, with some changes, the code used for InstantTranslate commands (e.g.: converting script to methods). I elaborated some assumptions/facilities (questionable and editable, of course):

• considering that a form as "kb:prefix_sub-gesture", where _ can be underscore, comma, space and so on, would be very annoying and redundant to write, I thought to dict solution, similar to __gestures, such as in InstantTranslate;
• the script that launches layer mode must call startLayering method, in the class mentioned above (in practice, self.startLayering());
• this method takes a gestureMap as optional parameter (default to None): if specified, use that; if None, then it searches to a __layeredGestures dict (same as but distinct from __gestures). So, you can have a single gesture with sub-gestures, and you simply call self.startLayering(), or multiple gestures with sub-gestures, and then you call self.startLayering(appropriate_sub-gestures_dict).
• (only an idea) when no additional operations are necessary before entering in layered mode, and in presence of various gesture with sub-gestures, to minimize quite useless code, we could provide also a script_layer method, so to have __gestures with this script, that obviously will call startLayering, passing it None if a __layeredGestures is present, or a dict named with base-gesture (e.g.: __NVDAShiftT) in case of multiple gesture with sub-gestures;

And ok, excluding the last point, it seems to work (I don't hear beeps, but probably it's a misconfiguration in my system audio). The problem is, as Jamie said, the input help mode.
I tried to assign a runInHelpMode boolean property to script for base gesture, modifying the handler method in inputCore.py to run script if that property exists, but unfortunately, pressing base gesture, happens what Jamie wrote in first comment, and I don't understand why. :(

Comment 5 by jteh (in reply to comment 4) on 2015-09-26 22:22
Thanks for looking into this.

Replying to ABuffEr:

• considering that a form as "kb:prefix_sub-gesture", where _ can be underscore, comma, space and so on, would be very annoying and redundant to write, I thought to dict solution, similar to __gestures, such as in InstantTranslate;

I get that the prefix is redundant/tedious, but I'm not a fan of having separate gesture dicts. This doesn't fit well into the current input framework, is difficult to handle for input help, can't be assigned in global gesture maps (e.g. gestures.ini and braille display drivers), etc.

Honestly, I'm against the idea of layered key strokes. Even though there are lots of add-ons nowadays, there are still quite a lot of unused keystrokes. There are only a few nvda+alt based key strokes in use by NVDA core. Furthermore, there are shift+alt+nvda key strokes that are still available, and how about windows+nvda, control+windows+nvda, etc?

Because a layer is easier for users to rember, and some users have lots of trouble making hard keystrokes.

cc: @nvdaes, @mltony, @abdel792, @javidominguez it seems we need some more discussion on this. While I clearly see the advantages of having layered gesture maps or prefix gestures (i.e. for people who cannot use a keyboard with both hands), I also understand Jamie'scomments here. Especially if an addon crashes and the layer gesture is being pressed, there is no way to exit it.

I wonder if it is possible to instruct the watchdog in NVDA to disable the addons in case of a crash until NVDA is restarted? I guess the layer gesture would be released when the coresponding addon is disabled. Right?
So the first action for the watchdog before terminating NVDA would be to disable the addons first.

cc: @josephsl, @jcsteh

"A number of NVDA add-on writers has expressed concerns that, with the increasing number of add-ons, the probability of an add-on gesture colliding with built-in commands would increase." @josephsl foretold accurately, as conversations around key conflicts have risen in recent times. Also, I want to second #3687, because I have noticed that new users - and perhaps users with learning differences - can get overwhelmed by too many 3-4 key combinations. By allowing the user to focus on one or two keys at a time and by making it possible for add-on authors to pick more intuitive key assignments from an expanded pool of shortcuts, layered commands may prove very beneficial. I do want to acknowledge the concerns raised in #3687 (comment) though. @LeonarddeR Any updated thoughts? @seanbudd What's NV Access's current position on this?