Comment 1 by jteh on 2008-10-27 03:03
This raises some issues with regard to keyboard layouts:

• In which keyboard map should the braille display keys be placed?
  • They certainly aren't specific to desktop or laptop layouts.
  • One option is to place them in their own "braille" map. This requires that multiple key maps be loaded simultaneously.
• Should there be a different keyboard map for each display?
  • This probably makes sense, as each display is essentially a different keyboard layout.
  • However, the keys would still need to be differentiated; e.g. brltty_windn, not just windn. This is necessary so that they can be differentiated from other keys.
    We probably need to refactor our keyboard layout system to take this into account. There is also other dissatisfaction with the current system, so a refactor should take all of this into account.

Comment 2 by SamuelThibault on 2008-11-06 08:56
Note: the brlapi.KEY_CMD_* commands should already be generic. Of
course not all devices support them all, but a generic keymap should
already be quite fine. We could make a survey of which devices provide
which in brltty. Now, you can also use the driver parameter of
enterTtyMode to get raw keycodes as read by brltty from the device, to
define device-specific keymaps. These could be shared with other
drivers' keymaps.

Comment 3 by jteh (in reply to comment 2) on 2008-11-06 09:46
Replying to SamuelThibault:

Note: the brlapi.KEY_CMD_* commands should already be generic. Of

course not all devices support them all, but a generic keymap should

already be quite fine.

It is my attention to use this generic mapping for the BRLTTY driver. These still need to bind to scripts in NVDA, so the mechanism still needs to be developed.

Now, you can also use the driver parameter of

enterTtyMode to get raw keycodes as read by brltty from the device, to

define device-specific keymaps.

I think that those using BRLTTY may already be familiar with BRLTTY key bindings, so it would be best to use those (generic) keys. Of course, some of these don't map so well to a Windows GUI screen reader and we may have to fudge this a little.

Comment 4 by jteh on 2009-06-23 05:40
Changes:
Milestone changed from 0.6 to 0.7

Comment 5 by mdcurran on 2009-12-08 02:03
Not in 2010.1, but possibly 2010.2

Comment 6 by jteh on 2009-12-08 05:00
Forgot to change the milestone.
Changes:
Milestone changed from 2010.1 to 2010.2

Comment 7 by jteh on 2010-03-18 06:57
Changes:
Milestone changed from 2010.2 to 2010.3

Comment 10 by jteh on 2010-12-06 02:29
http://bzr.nvaccess.org/nvda/brailleGestures/

Comment 11 by jteh on 2010-12-08 08:04
Core work is pretty much done.

The alvaBC6 driver is the only driver that has been updated so far.

Mick, feel free to update the freedomScientific driver whenever you are able.

Comment 12 by bramd on 2010-12-20 00:16
I just added quite some key bindings to the Handytech driver based o the code in the main branch. I will port this to the new brailleGesture system and post a patch here when I'm done.

However, I also added a very basic braille input mode that allows typing braille using the braille keyboard based on the current translation table. I'm not sure yet if I can make that more generic and port it to gestures.

Comment 13 by jteh (in reply to comment 12) on 2010-12-20 05:05
Replying to bramd:

I just added quite some key bindings to the Handytech driver based o the code in the main branch. I will port this to the new brailleGesture system and post a patch here when I'm done.

Great! Note that I haven't yet converted the existing code to use the new system. If I do, it will probably conflict with your patch. Do you want me to hold off and wait for your patch; i.e. your patch will update the driver for the new code? Note that this needs to be done fairly soon, so if you won't have time to do this soon, I'll do the initial conversion and you can submit a patch after that is done.

However, I also added a very basic braille input mode that allows typing braille using the braille keyboard based on the current translation table. I'm not sure yet if I can make that more generic and port it to gestures.

This should really be done in a more generic fashion and is covered by #808. I haven't really figured out how to make it more generic myself yet, as this won't be done for 2011.1.

Comment 14 by bramd on 2010-12-23 13:47
Just realized I didn't gat an email notification about my own patch, so I abuse this comment to bring it to your attention.

Furthermore, please note that the hotkey for the server configuration dialog does not work yet. I have to see if I implemented the command right, did not have the time for that.

This driver has been tested with the Easy Braille and should work with all Handytech devices and provide reasonable keys on all of them. Next week I've the opportunity to test more devices and expand the key assignments if needed.

Comment 15 by jteh on 2011-01-03 23:03
@bramd: It looks like your patch is against an older version of your code which included the braille typing keys, so I can't apply it. Can you provide a patch based on handyTech.py from current main or brailleGestures? Thanks.

Comment 16 by jteh on 2011-01-05 11:01
Merged in d8a83c2. I'll leave this open until the updated Handy Tech driver gets committed.

Comment 17 by bramd (in reply to comment 15) on 2011-01-06 12:39
Replying to jteh:

@bramd: It looks like your patch is against an older version of your code which included the braille typing keys, so I can't apply it. Can you provide a patch based on handyTech.py from current main or brailleGestures? Thanks.

Wow, I know it was late when I created the patch, but that's a big fail from me. Just updated the patch, it's against main now. I also fixed some issues regarding the config dialog, which was not working in the previous version.

The driver has been tested with an Easy Braille and a Braille Star. I may add more useful key bindings later.

Comment 18 by jteh on 2011-01-07 00:07
Nice work. Thanks!

Some code review:

@@ -25,15 +31,17 @@

...

  if constants.KEY_ROUTING in keys:

•     try:
  

•         inputCore.manager.executeGesture(InputGesture(keys, routing_pos -1))
  

•     except inputCore.NoInputGestureAction:
  

•         pass
  

• else:
  

•     try:
  

Probably more readable to set gesture to a variable here and then execute outside the if.

@@ -48,10 +56,30 @@

...

def init(self):

...

• HT_KEYS = {
  

Probably change this to gather the keys from constants.__dict__ as discussed on IRC. This will also cover the currently missing key names.

• script_showConfig.doc = _("Show the Handytech driver configuration window.")

Please change this to "Handy Tech" for consistency.

+class InputGesture(braille.BrailleDisplayGesture):

...

• def init(self, keys, routing_pos=None):

...

• # Sort keys by name so  the order of keys in a combination is predictable
  

• names.sort()
  

You can't sort the names like this for the id; they need to be in Python set order, as incoming gesture identifiers are always normalised to Python set order. I see this isn't actually documented anywhere; need to do that. :)

Comment 19 by jteh on 2011-01-07 05:38
@bramd: In f035649, I removed braille.!BrailleDisplayDriverWithCursor. Existing drivers must now subclass braille.!BrailleDisplayDriver instead and rename their _display method to display. I've already made the change for handyTech, but the class change will cause a merge conflict for you. It shouldn't be hard to fix, though. Sorry for being a nuisance. :)

Attachment handytech-gestures.diff added by bramd on 2011-01-08 01:06
Description:
Improved patch, implemented code changes as suggested in ticket comments

Comment 20 by bramd (in reply to comment 18) on 2011-01-08 01:13
Replying to jteh:

Nice work. Thanks!

Some code review:

Thanks, implemented your suggestions.

Comment 21 by jteh on 2011-01-08 07:10
Updated Handy Tech driver committed in 43c2052. Thanks Bram!

Closing this ticket as fixed. Technically, the lilli driver also needs updating, but this may not happen for some time and it still works as is. The core support is there, which is what this ticket was about.
Changes:
State: closed