Enhanced input gesture mapping

[aleksey_s]

Currently it is uncomfortable to maintain more than one nvda .kbd files, becouse you need add all new written scripts to all .kbd files. thus with oficially distributed key maps it isn't so difficult, with maps which have one user it isn't possible. this must be rewoked somehow.
may be as follow:
in .kbd files pairs of settings must be no keystroke=script, but script=keystroke. so we have main kbd file (now it is desktop), and how many as one's need extending files. when loading new map, some script keystroke may be changed, and some not. ofcourse, main map file must be loaded first of all, and just it will have all assotiations, other may have redefine just some of them.

[jteh]

I do acknowledge the problem here. However, this idea does not allow one script to be bound to multiple keys, which might be useful under certain circumstances.

Another option might be to provide a set of key bindings which are common to all keyboard layouts; i.e. a "common" keyboard layout. This would include keys such as NVDA+t, NVDA+f12, NVDA+upArrow, etc. which aren't likely to need to change in different layouts.

Out of interest, what is the use case for having different layouts here? There's obviously the laptop layout, but what other layouts are users creating?

[Bernd]

Replying to jteh:

I do acknowledge the problem here. However, this idea does not allow one script to be bound to multiple keys, which might be useful under certain circumstances.

Another option might be to provide a set of key bindings which are common to all keyboard layouts; i.e. a "common" keyboard layout. This would include keys such as NVDA+t, NVDA+f12, NVDA+upArrow, etc. which aren't likely to need to change in different layouts.

Out of interest, what is the use case for having different layouts here? There's obviously the laptop layout, but what other layouts are users creating?

I think Users will maybe write different maps if they have a program with an key command they need often so they don't have to pass the next key command to the aplication.

[jteh]

In the framework proposed in #601, all mappings will be included in a single map file. The syntax we think is best is rather Pythonic in nature and involves specifying the script only once with all of its input gestures. For example (note the indentation on the gesture lines):

dateTime:
 kb:common:NVDA+f12
 brl:baum:k2+k3+k4+k5
review_previousCharacter:
 kb:common:end
 kb:laptop:NVDA+m

Note that kb:common is common to both desktop and laptop layouts.
Does this satisfy your request?

[aleksey_s]

Replying to jteh:

In the framework proposed in #601, all mappings will be included in a single map file. The syntax we think is best is rather Pythonic in nature and involves specifying the script only once with all of its input gestures.

Does it allow to have user customized mappings? e.g. where not all bindings are redefined but only a few of them.

Does this satisfy your request?

Certainly.

[jteh]

Replying to aleksey_s:

Does it allow to have user customized mappings? e.g. where not all bindings are redefined but only a few of them.

Yes. There will be a single user map where users can define whatever gesture mappings they wish.

[jteh]

We've decided to go for a more ini-like format after all:

[package1.package2.class]
script = gesture1, gesture2, ...

[jteh]

Branch:  http://bzr.nvaccess.org/nvda/gestureMapping/

App modules no longer have external key map files. Instead, gestures are bound in the app module. There will be locale and user external gesture maps to allow internal bindings to be overridden.

[jteh]

Merged in changeset:main,3950.