Enhanced input gesture mapping #194

Closed
nvaccessAuto opened this Issue Jan 1, 2010 · 9 comments

2 participants

@nvaccessAuto

Reported by aleksey_s on 2008-10-11 06:38
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.
Blocked by #601
Blocking #810

@nvaccessAuto

Comment 1 by jteh on 2008-10-11 12:16
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?

@nvaccessAuto

Comment 2 by Bernd (in reply to comment 1) on 2009-02-22 02:32
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.

@nvaccessAuto

Comment 3 by jteh on 2009-05-01 01:23
Changes:
Milestone changed from 0.6 to None

@nvaccessAuto

Comment 6 by jteh on 2010-03-19 02:55
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?

@nvaccessAuto

Comment 7 by aleksey_s (in reply to comment 6) on 2010-03-20 06:40
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.

@nvaccessAuto

Comment 8 by jteh (in reply to comment 7) on 2010-03-20 12:45
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.

@nvaccessAuto

Comment 9 by jteh on 2010-10-22 06:40
We've decided to go for a more ini-like format after all:

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

Changes:
Changed title from "keystroke/script association must be improved somehow" to "Enhanced input gesture mapping"
Milestone changed from None to 2010.3

@nvaccessAuto

Comment 10 by jteh on 2010-10-27 01:06
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.

@nvaccessAuto

Comment 11 by jteh on 2010-11-26 05:04
Merged in 8ecfad4.
Changes:
State: closed

@jcsteh jcsteh was assigned by nvaccessAuto Nov 10, 2015
@nvaccessAuto nvaccessAuto added this to the 2011.1 milestone Nov 10, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment