[nvda] Re: Chancing key maps

Hi Jamie,
I guess cause NVDA is so modular it makes this hard. For specific appModule keys it will be good enough to just have a separate keymap file for each appModule, but really the
... Actually, this might work... I was just thinking about all the NVDA objects and virtual buffers with specific key bindings, but these all seem to be so that normal computer actions speak, as in tracking the arrow keys. So, in theory, perhaps all NVDA specific actions can be in appModules and therefore be in an external keymap, but keys with in NVDA objects and virtualBuffers etc, can only be limited to pre-defined actions that any person would do.
This means though something like insert+f which is specific to NVDAObject_textBuffer objects wouldn't be allowed... the appModule would have to have this, and only let it run if the object in question supported it. 

This will certainly make documenting keys a hell of a lot easier.
Also means something like say all will have to be in the default appModule, but it will only work if the object supports it.
I Suppose this also makes it nicer because there won't be conditions the users will ahve to think about before trying a key, it will be assigned everywhere, but if they can't do it it will say so.
I'm happy for you to devise some kind of file format if you like for each appModule keymap if you want... 

Mick
----- Original Message ----- From: "James Teh" <jamie@xxxxxxxxxxx> 
To: <nvda@xxxxxxxxxxxxx>
Sent: Sunday, November 26, 2006 7:15 PM
Subject: [nvda] Re: Chancing key maps



Hi Mick,
I need to have a look at the newer code to see whether this is possible, but one way of having dynamic key maps might be to register methods that take keys with names instead of keys. The names could then be tied to keys via a configuration file. Alternatively, the keys could just be registered by the hierarchical path to the method: 
appModules.blah.methodname=Control+Shift+X
appModules._default.exitNVDA=Insert+N
The base appModule and NVDAObject classes would provide a lookup method which searches the keys configuration for a matching key and checks whether the hierarchical path matches something in their class and, if so, it would execute the function.
A much simpler alternative is to just separate the keys and configuration specific stuff from the appModules and include them in separate files. If a non-Python file format was required, functions could easily be written to handle the loading of the files and execution of the register calls. Thinking about it, this latter method is far more flexible.
Thoughts? If you like any of these ideas, I'll have a bit of a look at the code and try to come up with something more solid. 

Jamie

Michael Curran wrote:

Hi all,
Noticing some queries about key maps for NVDA, I thought I'd better explain the current situation.
NVDA has levels of key maps, depending on what exactly you are dealing with.
When a key is pressed, firstly the current appModule is checked, then the current virtualBuffer (if any) and then the NVDA object with focus. 

There is no one key map for NVDA.
Actual key bindings can be found in appModules, in virtualBuffers and in NVDA objects in a dictionary instance variable called _keyMap. Usually keys are added by the __init__ method of these objects.
To add a key, you use registerScriptKey(key,script) or registerScriptKeys(dict) (where dict is a dictionary of key:script pairres). 

Anyone can change these key bindings by changing these functioncalls.
To represent a key, we usually use the function from keyboardHandler called key... key takes one parameter which is a string that represents a key press, made up of individual keys separated by pluses. 

For example: key("insert+n")
Please feel free to change any of these key bindings for your own copy of NVDA.
Currently there is no way to change the whole key bindings to suit a laptop, though in my experience most modern laptops do have a mode for using the number pad from the querty section.
If anyone can think of a good way to implement dynamic key bindings, please let me know.
I guess if its only the problem of the insert key, then perhaps we can make an "NVDA key" which can be changed, but I can't really see how you could completely ignore the number pad all together.
I am currently working on fixing up the NVDA api so it is much easier to automatically generate documentation for it, and then I (and anyone interested) can start writing a proper user guide and developer guide. 

Mick




To post messages to the list send email to
nvda@xxxxxxxxxxxxx
To unsubscribe from the list send a blank message to:
nvda-request@xxxxxxxxxxxxx
with 'unsubscribe' in the Subject field.
Thank you for your continued support of NVDA.


--
James Teh
Email: jamie@xxxxxxxxxxx
WWW: http://www.jantrid.net/
MSN Messenger: jamie@xxxxxxxxxxx
Jabber: jteh@xxxxxxxxxx
Yahoo: jcs_teh
To post messages to the list send email to
nvda@xxxxxxxxxxxxx
To unsubscribe from the list send a blank message to:
nvda-request@xxxxxxxxxxxxx
with 'unsubscribe' in the Subject field.
Thank you for your continued support of NVDA.



To post messages to the list send email to
nvda@xxxxxxxxxxxxx
To unsubscribe from the list send a blank message to:
nvda-request@xxxxxxxxxxxxx
with 'unsubscribe' in the Subject field.
Thank you for your continued support of NVDA.

Other related posts: