Comment 2 by sthibaul on 2010-10-28 11:17
Mmmm, isn't this already handled by brltty? Of course, there's the
issue of the braille table, and people will probably like to be able to
type contracted text, so it'll be better to support it in NVDA. It only
has to support the dot-pattern key events, however, the rest is already
simulated by brltty.

Comment 3 by jteh (in reply to comment 2) on 2010-10-28 22:27
Replying to sthibaul:

Mmmm, isn't this already handled by brltty?

Yes, but many users use native (non-BRLTTY) NVDA drivers. That said, we do let BRLTTY pass key presses through to the OS as an interim solution.

Comment 4 by orcauser on 2011-02-13 12:21
It isnt just a matter of catching keypresses, but the dot combination should be run through liblouis backtranslate to get the correct actual input.

For example dot 1, in an english translation table is the letter a, but the same dot using the arabic translation table is the letter alif.

Some arabic users have also requested for this feature.

Thank you.

Comment 5 by jschmude on 2011-04-26 21:27
Should 601 still be blocking this, now that 601 has been closed?

Comment 6 by jteh on 2011-04-26 23:35
There's no reason to remove the blocked info. It still depends on the functionality of #601, even though that has now been implemented. Blocked only means "can't implement" if the referenced ticket is still open.

Comment 7 by waelzakareya on 2011-11-01 14:49
Changes:
Changed title from "NVDA should support either grade1 or grade2 braille input" to "NVDA should support braille input either grade1 and/or grade2"

Comment 8 by zhaoyu on 2012-05-01 03:11
brltty support our mini braille display, but when I use brltty with NVDA, the braille display cells and navigator keys work well, but the braille input key do not work. So is there any method to solve this problem?

Comment 10 by jteh (in reply to comment 8) on 2012-06-12 06:15
Replying to zhaoyu:

brltty support our mini braille display, but when I use brltty with NVDA, the braille display cells and navigator keys work well, but the braille input key do not work. So is there any method to solve this problem?

This is a separate issue from this ticket, as this ticket relates to NVDA's native support for this. Your issue suggests BRLTTY isn't handling the braille input keys. Please ensure you're running the latest version of BRLTTY. Failing that, please test this with BRLTTY in a command prompt without NVDA running. If it doesn't work there, NVDA is not the cause. This is probably better discussed in a new ticket or on the nvda-dev email list.

Comment 11 by jteh on 2012-10-19 07:49
Changes:
Milestone changed from None to 2013.1

Comment 12 by jteh on 2012-10-24 05:48
I spun off #2439 for contracted braille.

In high level terms (we can get to fine details later), there are several parts to this work:

1. Create an input gesture which can support braille dot input.

• We need to work out whether braille input will only be done from braille displays or whether we should separate braille input and output. That is, will there ever be braille keyboards that aren't also braille displays? I'm tempted to say we should separate it, though I don't know of any standalone braille keyboards right now.
  1. Create a script bound to this gesture which does the braille translation and outputs the appropriate character.
  2. Provide a way to select different tables for input and output.
• This is particularly important right now because we will only initially support computer braille input. Even when we do support contracted braille, users may still want to read and write in different braille grades.
• There are two options:
  1. Provide separate selections for input and output table. This is simplest, but it does allow users to use entirely different braille codes (e.g. different languages) for input and output, which is pretty odd.
  2. Allow the user to select a computer braille table, an uncontracted braille table and a contracted braille table. Alternatively, only allow the user to select a broad braille code and have these tables predefined. This enables fast switching between output grades. Input would (for now) always use the computer braille table.
     This is probably the most controversial question. Can anyone think of a reason (other than implementation complexity) against option 2 or a major reason to prefer option 1? Of course, implementation complexity is a valid concern. Maybe we should do option 1 initially and then option 2 later, though that means breaking user configs twice.
  3. Implement support for devices. :)
     Changes:
     Changed title from "NVDA should support braille input either grade1 and/or grade2" to "Support for entry of computer braille via a braille keyboard"

Comment 13 by jteh on 2012-10-24 05:51
One other question is whether we should implement unified handling of space+dots combinations (cords) for special functions; e.g. modifiers. If we do, should each combination be mapped to a separate gesture?

Comment 14 by ruifontes (in reply to comment 12) on 2012-10-24 12:00
Replying to jteh:

1. Create an input gesture which can support braille dot input.
   • We need to work out whether braille input will only be done from braille displays or whether we should separate braille input and output. That is, will there ever be braille keyboards that aren't also braille displays? I'm tempted to say we should separate it, though I don't know of any standalone braille keyboards right now.

You have Braille keyboard stand alone from Arpo, or Harpo, from Poland, named BraillePen; from ONCE, Spanish association of blind, I don't remember the name of the keybord and from Handytech.

Comment 15 by ragb (in reply to comment 12) on 2012-10-24 13:48
Here we go:
Replying to jteh:

In high level terms (we can get to fine details later), there are several parts to this work:

1. Create an input gesture which can support braille dot input.
   • We need to work out whether braille input will only be done from braille displays or whether we should separate braille input and output. That is, will there ever be braille keyboards that aren't also braille displays? I'm tempted to say we should separate it, though I don't know of any standalone braille keyboards right now.

As Rui Fontes Pointed out on comment:14, there seems exist some of these keyboards. Anyway, I don't think separating input and output imposes much more complexity than keeping the support only on the braille-display system, they seem somehow independent. With this, someone could probably find a way to use the qwerty keyboard to do braille input. So I'm for the separation of conserns from braille input and output. Of course braille display drivers have to implement the input gesture creation and so on.

1. Create a script bound to this gesture which does the braille translation and outputs the appropriate character.

Agreed.

1. Provide a way to select different tables for input and output.
   • This is particularly important right now because we will only initially support computer braille input. Even when we do support contracted braille, users may still want to read and write in different braille grades.
   • There are two options:
   1. Provide separate selections for input and output table. This is simplest, but it does allow users to use entirely different braille codes (e.g. different languages) for input and output, which is pretty odd.

Agreed. Not so good user experience.

1. Allow the user to select a computer braille table, an uncontracted braille table and a contracted braille table. Alternatively, only allow the user to select a broad braille code and have these tables predefined. This enables fast switching between output grades. Input would (for now) always use the computer braille table.

This is similiar from what voiceover does on OSX. We select the language and if you want computer braille, uncontracted or whatever (it is not so well designed but the overall idea is good, we can do much better).

This is probably the most controversial question. Can anyone think of a reason (other than implementation complexity) against option 2 or a major reason to prefer option 1? Of course, implementation complexity is a valid concern. Maybe we should do option 1 initially and then option 2 later, though that means breaking user configs twice.

If liblouis had some way to determine table language, contraction, etc (further than naming convention) it woud easy implementation. But we can simply hardcode that. However there is the problem of existing many contraction tables for the same language, not only grade 1 and 2. For instance in portuguese there are two "standards" of braille contractin(althoug one is quit old but some people use and there is an unoficial liblouis table for it). O course option 1 would be easier, but I do believe we should try option 2, if we can think of a good user experience for this.

1. Implement support for devices. :)

Boring part... :).

Comment 16 by ragb (in reply to comment 13) on 2012-10-24 13:54
Replying to jteh:

One other question is whether we should implement unified handling of space+dots combinations (cords) for special functions; e.g. modifiers. If we do, should each combination be mapped to a separate gesture?

I'm not quit sure if we should do this. On one hand, it is fgood and elegant to have these combinations standardized, makes documentation easier and all maintenance. However, must notetakers and braille displays have their known set of combinations, either but the notetaker usage pattern or writen in the manuals, for other screen readers (i.g. Focus displays). Having too much different combinations from what users are used too may be sort of confusing.

Even with some counter-arguments, I'd go for standardizing these cords, if possible.

Comment 17 by jteh on 2012-10-24 23:33
Regarding multiple braille codes for one language, a braille code (e.g. Unified English Braille Code, which is used in Australia) could define tables for each grade (computer braille, uncontracted and contracted). So, rather than tying this to language, we tie it to braille code. Does this solve the issue for Portuguese?

One problem this doesn't solve is that some languages seem to have more than three grades. German seems to have computer braille and grades 0, 1 and 2. For these languages, the categories computer braille, uncontracted and contracted aren't sufficient, which creates somewhat of a problem. Maybe we need to have a variable number of grades per code, but that makes the UI for choosing grades inconsistent and thus difficult to manage.

There may even be languages where computer braille isn't even a valid concept, which will cause serious problems for input. In that case, I guess input just has to use the first grade.

Regarding cords, most displays have other buttons they can use for their own combinations. However, perhaps there are displays that only have braille keys. In that case, I guess they can choose not to use the unified cords support.

I'm still not sure whether to map individual cords to separate gestures or not. Pure dots will all be mapped to one gesture and script, but cords may all have somewhat different functionality, so it may make sense to map them all to separate gestures so we have separate scripts for each cord. That one is tricky.

Comment 18 by ragb (in reply to comment 17) on 2012-10-27 14:17
Replying to jteh:

One problem this doesn't solve is that some languages seem to have more than three grades. German seems to have computer braille and grades 0, 1 and 2. For these languages, the categories computer braille, uncontracted and contracted aren't sufficient, which creates somewhat of a problem. Maybe we need to have a variable number of grades per code, but that makes the UI for choosing grades inconsistent and thus difficult to manage.

That's the problem for portuguese. Grade 1 is uncontracted, grade 2, contracted, and there is the other contracted standard (call it grade 3, as it doesn't seem to have and name for it).

There may even be languages where computer braille isn't even a valid concept, which will cause serious problems for input. In that case, I guess input just has to use the first grade.

Hmm. Ticky. But yes, grade 1 may work as fallback solution.

Regarding cords, most displays have other buttons they can use for their own combinations. However, perhaps there are displays that only have braille keys. In that case, I guess they can choose not to use the unified cords support.

Yes. And there are some displays (as the braillenote) which intercept some cords and don't send them to the screen reader.

I'm still not sure whether to map individual cords to separate gestures or not. Pure dots will all be mapped to one gesture and script, but cords may all have somewhat different functionality, so it may make sense to map them all to separate gestures so we have separate scripts for each cord. That one is tricky.

If I had to choose I'd say one gesture only. Because 1. With singular gestures with would had many duplicate mappings in everydisplay and 2. If some display wants to use a cord for diferent porposes then the standard, it could intercept it before creating a standard cord gesture.

But as you say, that is quit tricky.

Comment 19 by jteh (in reply to comment 18) on 2012-10-29 07:06
Replying to ragb:

That's the problem for portuguese. Grade 1 is uncontracted, grade 2, contracted, and there is the other contracted standard (call it grade 3, as it doesn't seem to have and name for it).

Is grade 3 part of the same braille standard or is it separate? For example, English U.S., English U.K. and UEBC all use the same computer braille table, but have different grade 1 and 2 tables. If the Portuguese contracted tables are actually separate standards, perhaps they should be treated as separate braille codes which happen to share the same computer braille and uncontracted tables.

I'm still not sure whether to map individual cords to separate gestures or not.

If I had to choose I'd say one gesture only. Because 1. With singular gestures with would had many duplicate mappings in everydisplay

Woops. I forgot these would have to be mapped for each display. I'd sort of imagined they'd be global, but you're right, it doesn't work like that. (Don't you love it when you forget how your own code works?)

and 2. If some display wants to use a cord for diferent porposes then the standard, it could intercept it before creating a standard cord gesture.

That'd actually be easier to handle with multiple gestures, not one single gesture. Or am I misunderstanding you?

Comment 20 by ragb (in reply to comment 19) on 2012-10-29 19:26
Replying to jteh:

Replying to ragb:

That's the problem for portuguese. Grade 1 is uncontracted, grade 2, contracted, and there is the other contracted standard (call it grade 3, as it doesn't seem to have and name for it).

Is grade 3 part of the same braille standard or is it separate? For example, English U.S., English U.K. and UEBC all use the same computer braille table, but have different grade 1 and 2 tables. If the Portuguese contracted tables are actually separate standards, perhaps they should be treated as separate braille codes which happen to share the same computer braille and uncontracted tables.

To be honest I don't know for sure. However, the portuguese braille standard entity (here in Portugal) is dead or something similar, which in practice means that there isn't anyone to tell if it is or not. I'll try talking with some people (mainly old guys that remeber the time when someone cared from actual braille standards) to know what they have to say.

I'm still not sure whether to map individual cords to separate gestures or not.

If I had to choose I'd say one gesture only. Because 1. With singular gestures with would had many duplicate mappings in everydisplay

Woops. I forgot these would have to be mapped for each display. I'd sort of imagined they'd be global, but you're right, it doesn't work like that. (Don't you love it when you forget how your own code works?)

Hmm, maybe you know it, it is me that don't :). We can bind the common gesture on the base braille display class, for instance, and then simply create these gestures on the concret classes. Of course this part means changing every display driver to create the same gestures when having dot patterns and space bar. Key names are different for most displays. bah... Boring.

and 2. If some display wants to use a cord for diferent porposes then the standard, it could intercept it before creating a standard cord gesture.

That'd actually be easier to handle with multiple gestures, not one single gesture. Or am I misunderstanding you?

No, you are right. Single gesture implies making almost a duplicate of the binding code again, which doesn't make sence. If some driver wants to override a cord gesture it can replace in the gesture map.

Comment 21 by jteh on 2012-11-08 02:53
More detailed design:

• There will be a brailleInput module which will contain most of the logic for handling braille input.
• brailleInput.!BrailleInputGesture will be the base class for all braille input gestures.
  • The important property is dots, which will be a set of all dots pressed.
  • For chords, there should either be a special constant (probably 0) for space or another property like isSpaceDown or something.
  • Normally, the ID for braille input gestures will just be "dots".
  • Chords will have two IDs: "space+dot1+dot2" (for example) for specific binding and "space+dots" for generalised binding.
• Gestures for specific braille displays can inherit from this new gesture as well as !BrailleDisplayGesture.
• A brailleInput.handleDots function will do the backtranslation and send the appropriate keyboard character to the OS.
  • For now, this could just use the configured braille table. This allows us to do the table selection refactor separately. Either way, it'll be referring to some table, so changing this isn't hard.
• There will be a braille_dots script in globalCommands which calls brailleInput.handleDots.
• There'll probably be a braille_chord script in globalCommands as well, though I'm not certain of exact details for this yet.

Things I'm not sure about:

• I can't decide whether the base !BrailleDisplayGesture class should inherit from !BrailleInputGesture or whether individual braille displays should make that choice depending on whether they support braille input.
• It'd be nice if users could customise chords in the user gesture map. However, this requires having separate bindings for every chord in each display again. Arrg.
  • One solution is to have braille chord gestures output both specific and generalised sources; e.g. "br(baum):space+dot1+dot2" and "bk:space+dot1+dot2". This way, the generalised gesture can be bound globally.
• We could have a generalised source for dots as well; e.g. "bk:dots". This way, each display doesn't have to bind the braille_dots script.

Comment 22 by nvdakor on 2012-11-08 03:46
As for dot labels, as far as I know, many displays have only one space bar key, so I think labeling it as dot 0 would be fine for now.

Comment 23 by ragb (in reply to comment 21) on 2012-11-09 13:52

The design seems quite good IMO. Just some comments.
Replying to jteh:
[...]

• The important property is dots, which will be a set of all dots pressed.
• For chords, there should either be a special constant (probably 0) for space or another property like isSpaceDown or something.

I'd prefer a property. Dot 0 seems like dot1 but counting from zero (that is kind of funny but might confuse us developers more than anyone else).

• Normally, the ID for braille input gestures will just be "dots".
• Chords will have two IDs: "space+dot1+dot2" (for example) for specific binding and "space+dots" for generalised binding.
• Gestures for specific braille displays can inherit from this new gesture as well as !BrailleDisplayGesture.

Do you think we need specific gestures for brailleDisplays? Can't just a braille display send these gestures without subclassing, say "bk:space+dots"» Maybe I'm not getting it.

• A brailleInput.handleDots function will do the backtranslation and send the appropriate keyboard character to the OS.
  • For now, this could just use the configured braille table. This allows us to do the table selection refactor separately. Either way, it'll be referring to some table, so changing this isn't hard.

Agreed.

• There will be a braille_dots script in globalCommands which calls brailleInput.handleDots.
• There'll probably be a braille_chord script in globalCommands as well, though I'm not certain of exact details for this yet.

As I' understand it it will be bound tho space+dots gesture. If so, that makes sence, however having space+dot1+dot2, etc. gesture makes the pssibility to bind diferent scripts.

Things I'm not sure about:

• I can't decide whether the base !BrailleDisplayGesture class should inherit from !BrailleInputGesture or whether individual braille displays should make that choice depending on whether they support braille input.

I thing braille displays should make that choice.

• It'd be nice if users could customise chords in the user gesture map. However, this requires having separate bindings for every chord in each display again. Arrg.

Hmm. If the display creates general gestures for chords (space+dot1+dot2) I think we can have some global object where to bind the scripts. Does that make sence?

• One solution is to have braille chord gestures output both specific and generalised sources; e.g. "br(baum):space+dot1+dot2" and "bk:space+dot1+dot2". This way, the generalised gesture can be bound globally.

But if it generates two gestures, don't have the problem of some keypress originating two diferent actions at the same time?

• We could have a generalised source for dots as well; e.g. "bk:dots". This way, each display doesn't have to bind the braille_dots script.

I'd vote for that. If some display want specific bindings it could still do it, when creating gestures. For chords I0m not sure.

Comment 24 by jteh (in reply to comment 23) on 2012-11-10 03:06
Replying to ragb:

• For chords, there should either be a special constant (probably 0) for space or another property like isSpaceDown or something.

I'd prefer a property. Dot 0 seems like dot1 but counting from zero (that is kind of funny but might confuse us developers more than anyone else).

It could be -1 or even the string " ". Of course, there'd be a SPACE constant anyway. It also just occurred to me that space alone probably needs to be mapped to the dots script, so having it as a property is kinda weird.

Do you think we need specific gestures for brailleDisplays? Can't just a braille display send these gestures without subclassing, say "bk:space+dots"» Maybe I'm not getting it.

The idea behind specific gestures is that it can be overridden for a particular braille display if necessary. More explanation below.

• One solution is to have braille chord gestures output both specific and generalised sources; e.g. "br(baum):space+dot1+dot2" and "bk:space+dot1+dot2". This way, the generalised gesture can be bound globally.

But if it generates two gestures, don't have the problem of some keypress originating two diferent actions at the same time?

No. NVDA tries all identifiers and stops at the first one that produces an action. That's how keyboard layouts work. A keyboard gesture has two identifiers; e.g. kb(desktop):NVDA+1 and kb:NVDA+1. This way, you can override for a specific layout, but you can still have generalised bindings. I realise this is a bit confusing, but it allows for a lot of flexibility. :)

Comment 25 by ragb (in reply to comment 24) on 2012-11-10 13:23
Replying to jteh:

Replying to ragb:

• For chords, there should either be a special constant (probably 0) for space or another property like isSpaceDown or something.

I'd prefer a property. Dot 0 seems like dot1 but counting from zero (that is kind of funny but might confuse us developers more than anyone else).

It could be -1 or even the string " ". Of course, there'd be a SPACE constant anyway. It also just occurred to me that space alone probably needs to be mapped to the dots script, so having it as a property is kinda weird.

Yes, makes sence. Even dot0 works, is just a matter of ones preference.

No. NVDA tries all identifiers and stops at the first one that produces an action. That's how keyboard layouts work. A keyboard gesture has two identifiers; e.g. kb(desktop):NVDA+1 and kb:NVDA+1. This way, you can override for a specific layout, but you can still have generalised bindings. I realise this is a bit confusing, but it allows for a lot of flexibility. :)

No, that is really nice. I'm looking now properly at inputCore and I see the InputGesture.identifiers property. I understand now your ponit, I agree with it.

Comment 26 by jteh on 2012-11-28 05:15
Rui, did you have plans to implement this yourself or should it just be whoever gets to it first?

Comment 27 by ragb (in reply to comment 26) on 2012-11-28 14:17
Replying to jteh:

Rui, did you have plans to implement this yourself or should it just be whoever gets to it first?

I have some plans to do it but as things stand now I can't tell you when I might be able to start. So I'd say who comes to it first.

Comment 28 by ragb on 2012-11-30 20:38
Hi,

Thinking about this, I believe a quick prototype is quite simple to implement, at least for proof of concept. As it is rainning alot here and I can't much more I'm doing it right now. Will publish a branch shortly.

Comment 29 by jteh on 2012-12-02 23:56
Looks great as a prototype. :) For the real implementation, the gesture stuff needs to be split out into a separate gesture class in !BrailleInput. I'm still wondering whether it should use a prefix of "bk:" instead of "br:" as well.

I'm beginning to wonder about the term "chord". Technically, a chord is just pressing any combination of keys; i.e. more than one key. So, even dot1+dot4 is a chord. Where did the usage of chord to mean space+dots actually come from? Is there any formal reference defining this? If not, I'm tempted to call that "chord" variable "isSpaceDown" or similar.

Out of interest, when sending characters, is there any reason you didn't use keyboardHandler.KeyboardInputGesture.fromName to generate a gesture for the character and then call send() on that gesture? The way you've done it is more direct, but it makes sense to reuse existing code where we can.

In core.resetConfiguration, it probably isn't necessary to reset brailleInput, since it doesn't have any state at this point.

Comment 30 by nvdakor on 2012-12-03 04:40
Hi,
I think the term was first used that way when Braille 'n Speak came out in 1987. Since then, the term got "stuck".
I think, for sake of easier documentation and for consistency, we should label spacebar with "D9" or D0 in case a display has two space bars (on some Baum displays) or no space bar at all.

Comment 31 by ragb (in reply to comment 29) on 2012-12-03 12:58
Replying to jteh:

Looks great as a prototype. :) For the real implementation, the gesture stuff needs to be split out into a separate gesture class in !BrailleInput. I'm still wondering whether it should use a prefix of "bk:" instead of "br:" as well.

Hmm. I'm not sure of this. This implementation as the benefit that we can have various gesture identifiers, that is:

1. Specific !brailleDisplay gesture.
2. Generic chord / dots gesture with plain dots (i.g. dot1+dot2).
3. Dots gesture with bitmask for braille input.

The benefit I see is making it compatible with previous gesture maps, but that means some gestures confluct with braille input. The implementation is easier on the braille display driver side.

But as I say, I'm not quite sure of this. I'm just stating arguments in favor of my implementation :). I can give some in favor of yours too :).

I'm beginning to wonder about the term "chord". Technically, a chord is just pressing any combination of keys; i.e. more than one key. So, even dot1+dot4 is a chord. Where did the usage of chord to mean space+dots actually come from? Is there any formal reference defining this? If not, I'm tempted to call that "chord" variable "isSpaceDown" or similar.

I think I've seen it on some braille notetaker manuals and such. But in truth !isSpaceDown, or !spaceBar or whatever sounds better and avoids confusion.

Out of interest, when sending characters, is there any reason you didn't use keyboardHandler.KeyboardInputGesture.fromName to generate a gesture for the character and then call send() on that gesture? The way you've done it is more direct, but it makes sense to reuse existing code where we can.

Two main reasons:

1. keyboardHandler.KeyboardInputGesture.fromName} doesn't seem to work for many unicode characters (user32.VkScan}) trhows lookup error. I think it is suposed too, since keyboards only can write some of keys.
2. Probably we will need to send many characters at a time, for instance with contracted braille, when implemented. It is more eficient, anyway.

In core.resetConfiguration, it probably isn't necessary to reset brailleInput, since it doesn't have any state at this point.

Hmm, your right.

Comment 32 by jteh (in reply to comment 31) on 2012-12-03 22:15
Replying to ragb:

For the real implementation, the gesture stuff needs to be split out into a separate gesture class in !BrailleInput.

Hmm. I'm not sure of this.

This was discussed in comment:14 and comment:15. Separating Braille input and output requires a separate input gesture class.

This implementation as the benefit that we can have various gesture identifiers, that is:

You can do that with a separate gesture class as well. Braille displays that want Braille input will inherit from both. There's a bit of weird coupling in the gesture classes, but it still allows input to be used separately.

Out of interest, when sending characters, is there any reason you didn't use keyboardHandler.KeyboardInputGesture.fromName to generate a gesture for the character and then call send() on that gesture?

1. keyboardHandler.KeyboardInputGesture.fromName} doesn't seem to work for many unicode characters (user32.VkScan}) trhows lookup error. I think it is suposed too, since keyboards only can write some of keys.

Ah. I wouldn't have thought Windows allowed this for any method, but if it works correctly with your method, that's fine. The only problem I see is that in future, we'll need to handle modifiers as well.

Comment 80 by jteh (in reply to comment 79) on 2013-01-24 13:52
Replying to halim:

the baum driver was a bad example :-(.

Oh. I think I know what you're getting at. The idea is that the driver should be able to override Braille input keys if they wish. However, if the driver doesn't map them, it will use global mappings. Currently, there is no global mapping of space+dots combinations, but the idea is that there should be eventually.

in this example gesture: "kb:control+home": ("br(braillenote):space+d1+d2+d3",),

nvda would expect the keys in the same key order

space+d1+d2+d3 will work but not d1+d2+d3+space or d1+space+d3+d2 and so on.

It works because the identifier is always output in Python set order. When handling gesture mappings containing the plus sign, NVDA normalises them into Python set order. So, as long as the driver returns identifiers in Python set order, they match.

Comment 81 by jteh on 2013-01-24 13:56
To explain the set order thing, maybe an example will help:

>>> "+".join({"space", "d1", "d2", "d3"})

'space+d2+d3+d1'

The order Python uses for sets is indeterminate, but it will always be the same for a set containing the same values. We use this so that gesture identifiers match no matter what order you put their parts in.

Comment 82 by jteh on 2013-01-24 13:58
Rui, we should consider removing the explicit bindings for !BrailleNote and making global bindings.

Comment 83 by ragb (in reply to comment 76) on 2013-01-24 14:01
Replying to jteh:

Rui, is there any reason not to merge this; i.e. are there any outstanding issues with 8 dot input? There are still bugs in some of the drivers, but those can be addressed separately.

I think nothing is preventing it. Do you think we should document the displays that support input somehow specially (or those who still don't)? Anyway this can be handled separately.

Comment 84 by halim (in reply to comment 82) on 2013-01-24 14:06
Replying to jteh:

Rui, we should consider removing the explicit bindings for !BrailleNote and making global bindings.

Can the brailledrivers add their own bindings as well?
and overwrite the global ones?
Eg: Braillex Trio proviedes many keybindings, which are documented in the Papenmeier trio user manual. My goal was to implement same key bindings. This will not confuse users and they don't have to learn different keycommands for different screenreaders etc.

In other words, I like the current approach :-).

Comment 85 by ragb (in reply to comment 82) on 2013-01-24 14:09
Replying to jteh:

Rui, we should consider removing the explicit bindings for !BrailleNote and making global bindings.

Hmm yes. Probably there are more drivers with those, further from !braillenote. I can take a look into it.

Comment 86 by ragb on 2013-01-24 14:36
Ok, at least FS and !brailleNote drivers have keybindings employing space and dots (probably some of the drivers that still don't support braille input have those too). There are some inconsistencies among the drivers, so we must define what bindings we will have globally. I find the fs bindings somehow consistent, as follows:

            "kb:backspace" : ("br(freedomScientific):dot7",),
            "kb:enter" : ("br(freedomScientific):dot8",),
            "kb:shift+tab": ("br(freedomScientific):dot1+dot2+brailleSpaceBar",),
            "kb:tab" : ("br(freedomScientific):dot4+dot5+brailleSpaceBar",),
            "kb:upArrow" : ("br(freedomScientific):dot1+brailleSpaceBar",),
            "kb:downArrow" : ("br(freedomScientific):dot4+brailleSpaceBar",),
            "kb:leftArrow" : ("br(freedomScientific):dot3+brailleSpaceBar",),
            "kb:rightArrow" : ("br(freedomScientific):dot6+brailleSpaceBar",),
            "kb:control+leftArrow" : ("br(freedomScientific):dot2+brailleSpaceBar",),
            "kb:control+rightArrow" : ("br(freedomScientific):dot5+brailleSpaceBar",),
            "kb:home" : ("br(freedomScientific):dot1+dot3+brailleSpaceBar",),
            "kb:control+home" : ("br(freedomScientific):dot1+dot2+dot3+brailleSpaceBar",),
            "kb:end" : ("br(freedomScientific):dot4+dot6+brailleSpaceBar",),
            "kb:control+end" : ("br(freedomScientific):dot4+dot5+dot6+brailleSpaceBar",),
            "kb:alt" : ("br(freedomScientific):dot1+dot3+dot4+brailleSpaceBar",),
            "kb:alt+tab" : ("br(freedomScientific):dot2+dot3+dot4+dot5+brailleSpaceBar",),
            "kb:escape" : ("br(freedomScientific):dot1+dot5+brailleSpaceBar",),
            "kb:windows" : ("br(freedomScientific):dot2+dot4+dot5+dot6+brailleSpaceBar",),
            "kb:windows+d" : ("br(freedomScientific):dot1+dot2+dot3+dot4+dot5+dot6+brailleSpaceBar",),
            "reportCurrentLine" : ("br(freedomScientific):dot1+dot4+brailleSpaceBar",),
            "showGui" :("br(freedomScientific):dot1+dot3+dot4+dot5+brailleSpaceBar",),

What do you think?

Comment 87 by halim on 2013-01-24 14:46
BrailliantB has also some bindings with dots.

However, I am not sure about the global keybindings.
@rui: The posted braillebindings from Freedomscientific are different from the bindings used from Braillex Trio.
EG. space+d7 = kb:escape
space+d1+d2+d3+d4+d5+d6 = kb:control+escape
...

Comment 88 by aliminator on 2013-01-24 14:50
The trio key combinations are as follows (excerpt from manual):
Enter Space + dot 8; alternatively: dot 8
Escape Space + dot 7
Left arrow Space + dot 1
Right arrow Space + dot 4
Up arrow Space + dot 2
Down arrow Space + dot 5
Page up Space + dot 3
Page down Space + dot 6
Home Space + dots 1,2
End Space + dots 4,5
Insert Space + dots 2,3
Del Space + dots 5,6
Backspace Space + dots 6,8; alternatively: dot 7

Theoretically, a global key binding should not differ from the ones of all (currently three) braille displays.
Otherwise users could get confused especially those who switch from another screen reader.
There might be global braille input commands but at least it should be possible to overwrite them by driver authors.

Comment 89 by ragb (in reply to comment 87) on 2013-01-24 15:00
Replying to halim:

BrailliantB has also some bindings with dots.

However, I am not sure about the global keybindings.

@rui: The posted braillebindings from Freedomscientific are different from the bindings used from Braillex Trio.

EG. space+d7 = kb:escape

space+d1+d2+d3+d4+d5+d6 = kb:control+escape

...

They are all inconsistent. Although we may end up changing usual keybindings (and so get some users confused) I believe we should leverage this oportunity to get all consistent, as much as possible. this is not easier in code (having most stuff globally), but even in documentation we only have one place to change.

Comment 90 by aliminator on 2013-01-24 15:40
Sounds sensible but I don't know whether users wouldn't be too confused in case of using multiple screen readers or by<
reading the braille display's manual.

Comment 91 by nvdakor on 2013-01-24 18:07
Hi,
As for default key bindings, we may need to assume a few things when writing this set:

• Some braille displays allow QWERTY input.
• Not all displays have space bar.
• Some displays does not use braille keyboard, such as Alva Sattellite series.
  As far as BN is concerned, you should not map the folowing space+dot combinations, as these are native to KeySoft: SPACE with E, H, I, O, R, Z, 123456. Under Apex, there is a bypass command to allow KeySoft commands to be used as part of a screen reader, whereas other models does not, hence creating inconsistent user experience. Thanks.

Comment 92 by jteh (in reply to comment 84) on 2013-01-25 00:59
Replying to halim:

Eg: Braillex Trio proviedes many keybindings, which are documented in the Papenmeier trio user manual.

Are they documented for the display as a whole or for individual screen readers? How do they account for differences in screen reader concepts?

In general:

• Regarding confusion with other screen readers, it's worth noting that a user has to learn different commands for the normal system keyboard, so it could be argued that having to learn new Braille input commands is the same.
• Screen readers have different concepts, so trying to make the bindings the same may not always work so well. This may limit what you can do with NVDA.
• Having different bindings also makes it difficult to support entry of modifiers, etc.
• It's worth noting that !VoiceOver on iOS has common mappings for Braille input keys across all displays.

That said, there seems to be a fair amount of resistance to global bindings.

Comment 93 by jteh (in reply to comment 83) on 2013-01-25 01:20
Replying to ragb:

Do you think we should document the displays that support input somehow specially (or those who still don't)?

I've already done this.

Merged in be2e0fd.
Changes:
State: closed

Comment 94 by ragb (in reply to comment 93) on 2013-01-25 11:33
Replying to jteh:

Replying to ragb:

Do you think we should document the displays that support input somehow specially (or those who still don't)?

I've already done this.

Oh, yes, you did. I'm doing so much context switches these days :).

Do you think I should open a ticket to handle global bindings? Although some resistance, I'm not convinced the current situation is anyway better.

Merged in be2e0fd.

Thank you :).

Comment 95 by jteh (in reply to comment 94) on 2013-01-25 22:54
Replying to ragb:

Do you think I should open a ticket to handle global bindings? Although some resistance, I'm not convinced the current situation is anyway better.

Please do. Personally, I prefer global bindings, but I don't actually own a display with Braille input keys, so it's probably unfair to enforce my opinion here. :)

Comment 96 by jteh (in reply to comment 70) on 2013-01-30 07:00
Replying to aliminator:

Both input and output tables are german 8-dots. Pressing NVDA+z folowed by some input in Notepad.

Writing: hello world. This is displayed correctly on the braille display.

Following unicode characters appered in Notepad instead of the string typed in: ⠓⠑⠇⠇⠕ ⠺⠕⠗⠇⠙

This is fixed in liblouis 2.5.2, which is now in NVDA.

Comment 97 by bdorer on 2015-07-24 21:08
Replying to jteh:

From what I've been told, Handy Tech seem to prefer to use their own Braille input handling for some reason. I'll discuss this with my contact at Handy Tech.