Support for entry of computer braille via a braille keyboard #808

Closed
nvaccessAuto opened this Issue Aug 4, 2010 · 96 comments

2 participants

@nvaccessAuto

Reported by mike.reiser on 2010-08-04 17:13
Nvda should be able to handle the input of braille from a braille keyboard on displays sutch as the refreshabraille 18, and translate it back to text so that people can type in braille if they wish and it still comes out in text. This is done by system access and other readers.

Blocked by #601
Blocking #1003, #2439

@nvaccessAuto

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.

@nvaccessAuto

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.

@nvaccessAuto

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.

@nvaccessAuto

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

@nvaccessAuto

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.

@nvaccessAuto

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"

@nvaccessAuto

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?

@nvaccessAuto

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.

@nvaccessAuto

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

@nvaccessAuto

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"
@nvaccessAuto

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?

@nvaccessAuto

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.

@nvaccessAuto

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... :).

@nvaccessAuto

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.

@nvaccessAuto

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.

@nvaccessAuto

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.

@nvaccessAuto

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?

@nvaccessAuto

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.

@nvaccessAuto

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.
@nvaccessAuto

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.

@nvaccessAuto

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.

@nvaccessAuto

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. :)

@nvaccessAuto

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.

@nvaccessAuto

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?

@nvaccessAuto

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.

@nvaccessAuto

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.

@nvaccessAuto

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.

@nvaccessAuto

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.

@nvaccessAuto

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.

@nvaccessAuto

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.

@nvaccessAuto

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

  1. Probably we will need to send many characters at a time, for instance with contracted braille, when implemented. It is more eficient, anyway.

Ah. I didn't read the code properly, so I didn't realise !SendInput actually sends them all at once. That makes sense. Sorry.

@nvaccessAuto

Comment 34 by jteh on 2012-12-03 23:08
I've split Braille input into its own gesture in brailleInput,5661. I can't test the driver, but hopefully, everything should work as it did before. Actually, if I'm understanding correctly, the space bar wouldn't previously have worked to enter a space and it should now.

Note that dots with no space do not output individual dots; e.g. bk:dot1+dot2. However, individual dots are provided for dots with space. I don't see any point in allowing people to globally bind commands to individual dots, since they should always be for input, but this is easily changed if anyone can see a good use case.

Rui, does this implementation make more sense now or do you see problems?

@nvaccessAuto

Comment 35 by ragb (in reply to comment 34) on 2012-12-04 00:36
Replying to jteh:

I've split Braille input into its own gesture in brailleInput,5661. I can't test the driver, but hopefully, everything should work as it did before.

I see you implemented !BrailleInputGesture as a mix-in or trait. I understood you wanted a separate class hierarchy or something, but this gives the best of both and is quite elegant.
The driver works as expected.

Actually, if I'm understanding correctly, the space bar wouldn't previously have worked to enter a space and it should now.

It still doesn't work because it's not bound globally. But the Freedom Scientific's driver binds to kb:space so I had no problem :).
I didn't implement it because i'm not sure about a small detail that can grow bigger.
Now braille space bar alone is bound to kb:space. The most obvious thing to do is to map it to send a space character and go. However, why not mapping it to kb:dots and having dots = 0?. This way it will be processed by the !BrailleInputHandler. For computer braille it doesn't matter at all, but I've been thinking about this and I believe I have a reasonable proposal to do contracted braille (I'll explain it on the proper ticket).

Note that dots with no space do not output individual dots; e.g. bk:dot1+dot2. However, individual dots are provided for dots with space. I don't see any point in allowing people to globally bind commands to individual dots, since they should always be for input, but this is easily changed if anyone can see a good use case.

Hmm yes. I can't get with an useful use case for this either. If someone gets along with one we change it.

Rui, does this implementation make more sense now or do you see problems?

Further from me space bar philosofical dobt I think it is quite good.

@nvaccessAuto

Comment 36 by jteh on 2012-12-04 00:42
Actually, regarding space, I just... screwed up. I fixed this in brailleInput,5663. :)

@nvaccessAuto

Comment 37 by jteh on 2012-12-04 03:10
I'm attaching a global plugin I wrote to enable Braille input via an English QWERTY keyboard (mostly for testing). It must be used in conjunction with the current brailleInput code.

  • To enable/disable: NVDA+z
  • For dots 1 to 8, there are two sets of keys, as some keyboards handle one or the other better:
    1. f d s j k l a ;
    2. r e w u i o q p
  • Some keyboards won't let you enter certain combinations of keys. There is nothing I can do about this.
@nvaccessAuto

Attachment qwertyBrailleInput.py added by jteh on 2012-12-04 03:12
Description:
QWERTY Braille input plugin.

@nvaccessAuto

Comment 38 by nvdakor on 2012-12-04 03:48
Hi,
I can get the plug-in to work using my wireless keyboard (Logitech). However, when I type individual braille dots for letters, NvDA sends U.S. grade 2 contractions such as:

  • I type :fj" for "C": NVDA sends "can".
  • I type "fdkfksdfsdfsfk " for "hello ": NVDA sends: "haveeverylikelikeO ".
  • When I press space key, NvDA sends space to the active window. I tested it using Notepad. The plug-in was installed on a portable version of brailleINput:5664 (which was built from source).
@nvaccessAuto

Comment 39 by jteh (in reply to comment 38) on 2012-12-04 05:22
Replying to nvdakor:

I can get the plug-in to work using my wireless keyboard (Logitech). However, when I type individual braille dots for letters, NvDA sends U.S. grade 2 contractions

That's because your braille table is set to U.S. grade 2 or similar. This is only meant for computer braille input, but there's no separate input and output tables yet.

@nvaccessAuto

Comment 40 by ragb on 2012-12-04 22:52
Hi,

It seems liblouis is triming whitespace on back-translation, so dot 0 (space) is taking no effect. Question: map bk:space to kb:space or make a special exception in brailleInput.BrailleInputHandler.input for dots 0? For computer braille both options work, in the future (#2439) space bar may have a litle more to do.

@nvaccessAuto

Comment 41 by jteh (in reply to comment 40) on 2012-12-04 23:12
Replying to ragb:

It seems liblouis is triming whitespace on back-translation, so dot 0 (space) is taking no effect.

I assume you are, but just to confirm, are you running brailleInput,5663? I fixed this issue there and it seems to work fine for me with English (U.S.( 8 dot computer braille. Can you please test with this table?

Question: map bk:space to kb:space or make a special exception in brailleInput.BrailleInputHandler.input for dots 0? For computer braille both options work, in the future (#2439) space bar may have a litle more to do.

If necessary, I prefer the second option to make life easier in future.

@nvaccessAuto

Comment 42 by ragb (in reply to comment 41) on 2012-12-04 23:45
Replying to jteh:

Replying to ragb:

It seems liblouis is triming whitespace on back-translation, so dot 0 (space) is taking no effect.

I assume you are, but just to confirm, are you running brailleInput,5663? I fixed this issue there and it seems to work fine for me with English (U.S.( 8 dot computer braille. Can you please test with this table?

It works. i screwed the fs driver and it wasn't working due to my fault. All working now with computer braille tables.

@nvaccessAuto

Comment 43 by ragb on 2013-01-03 14:46
Hi,

(I'm back on this).

I believe we need to define what sort of interface and choices we must have to select the input braille table. Choices (already discuced) fall on one of the following alternatives.

  1. Have to independent combo boxes to select braille output table and braille input table. For now, braille input table choices must be restricted to computer braille tables (more on this bellow)
  2. When selecting the output braille table, the input one is selected according to the language of the output, or we simply select language and then define if we want contracted, uncontracted or computer braille. This needs some way of knowing the characteristics of the available tables, such as grade, etc (probably we must hard code it on NVDA). This imposes some problems when there are no computer braille table for some language, or not all grades are available. It also needs many interface changes, specially if we go for the language selection option.

The first option is simpler, and gives the user the option to select different input and output languages (does anyone need that at all?). The second option requires more work, an I'm not sure about the "interface", i.g. can it be easy for the user to understand all that computer/contracted/uncontracted braille, and that they can only use computer braille for input?

@nvaccessAuto

Comment 44 by jteh (in reply to comment 43) on 2013-01-04 01:23
Replying to ragb:

  1. When selecting the output braille table, the input one is selected according to the language of the output, or we simply select language and then define if we want contracted, uncontracted or computer braille. This needs some way of knowing the characteristics of the available tables, such as grade, etc

Option 1 also requires this if you want the input tables to be restricted to computer Braille only.

This imposes some problems when there are no computer braille table for some language

Practically speaking, option 1 has this problem as well. It just affects the user, not the code; i.e. the user will end up with some table for another language.

It also needs many interface changes, specially if we go for the language selection option.

It's possible language isn't enough if there are multiple Braille codes for some languages. I'm still not clear on this. In Australia, UEB is the ratified code, but I'm not sure how this works for French, where there are also multiple codes.

@nvaccessAuto

Comment 45 by jteh on 2013-01-09 09:46
For now, let's go with separate input and output table selection. I've just added a bool for each table specifying whether it can support input. When we support input for something other than 8 dot computer braille, we may want to change this to provide more info. However, I think we need to start somewhere and it seems to be very difficult to make this entirely future proof.

@nvaccessAuto

Comment 46 by ragb (in reply to comment 45) on 2013-01-09 10:01
Replying to jteh:

For now, let's go with separate input and output table selection. I've just added a bool for each table specifying whether it can support input. When we support input for something other than 8 dot computer braille, we may want to change this to provide more info. However, I think we need to start somewhere and it seems to be very difficult to make this entirely future proof.

Ok. So will have an input braille combo box with all tables that support it and a new inputTable setting on the config, right?
What shall be done for braille display drivers? We can try adding input support to them but without displays for testing it would be harder.

I can do the interface part if you want, and add input to the brailleNote driver right away.

@nvaccessAuto

Comment 47 by ragb (in reply to comment 46) on 2013-01-09 11:25
Replying to ragb:

Ok. So will have an input braille combo box with all tables that support it and a new inputTable setting on the config, right?

Did this in brailleInput,5669.

If it's all well I will document it in braille settings section. Shall braille input be documented elsewhere, further from braille display entries that support it?

Changes:
Changed title from "Support for entry of computer braille via a braille keyboard" to "FSupport for entry of computer braille via a braille keyboard"

@nvaccessAuto

Comment 48 by ragb on 2013-01-09 11:26
Changes:
Changed title from "FSupport for entry of computer braille via a braille keyboard" to "Support for entry of computer braille via a braille keyboard"

@nvaccessAuto

Comment 49 by jteh (in reply to comment 47) on 2013-01-09 11:42
Replying to ragb:

Did this in brailleInput,5669.

Nice! Thanks. Two tiny things:
1. We should perhaps consider renaming "Translation table" to "Output table" in the GUI so it's clear what it does.
2. I wonder whether the word "Braille" in "Braille input table" is unnecessary.

If it's all well I will document it in braille settings section.

Please do.

Shall braille input be documented elsewhere, further from braille display entries that support it?

If you mean documenting whether each display supports input, I think it might be better to document the ones that don't support it, since eventually, all displays with Braille input keys will support it. Displays that don't have Braille input keys obviously don't need to mention it. Was there more documentation you had in mind?

@nvaccessAuto

Comment 50 by jteh (in reply to comment 46) on 2013-01-09 11:45
Replying to ragb:

What shall be done for braille display drivers? We can try adding input support to them but without displays for testing it would be harder.

I can probably add support to the brailliantB and baum drivers. I can have contacts at !HumanWare find people to test them. Other drivers will have to be updated by their authors.

@nvaccessAuto

Comment by jteh on 2013-01-09 11:53
(In #1003) I provided a global plugin to do this as part of my testing of #808. Whether this should be part of NVDA itself is yet to be determined, but my feeling right now is that it should be an add-on.

@nvaccessAuto

Comment 52 by ragb (in reply to comment 49) on 2013-01-09 12:16
Replying to jteh:

  1. We should perhaps consider renaming "Translation table" to "Output table" in the GUI so it's clear what it does.

Yes, it's probably better then "translation".

  1. I wonder whether the word "Braille" in "Braille input table" is unnecessary.

If we have "output table" and "input table" if think it is not needed, since the user can understand its purpose from the context.

Shall braille input be documented elsewhere, further from braille display entries that support it?

If you mean documenting whether each display supports input, I think it might be better to document the ones that don't support it, since eventually, all displays with Braille input keys will support it. Displays that don't have Braille input keys obviously don't need to mention it. Was there more documentation you had in mind?

I was thinking about documenting it in NVDA features, since the manual also says braille output. Moreover we should state somehow that only computer braille is supported (that can be on the settings dialog though). Has backspace and enter should be mapped (in most cases) to dot7 and dot8, I think we should document it in a general section (i.g. not display-specific). That's what I can think would be interesting, but I'm not sure of the proper places to put it.

@nvaccessAuto

Comment 53 by ragb (in reply to comment 52) on 2013-01-09 13:31
Change translation to output and remove braille from braille input table in brailleInput,5670. Added documentation in brailleInput,5671.

@nvaccessAuto

Comment 54 by nvdakor on 2013-01-09 20:25
Hi,
Testing the updated BN driver. Works flawlessly except only six dot input
is supported (which I understand).
As for describing this functionality, I agree that it should be done at the top of the user guide. We can say something like:

  • Supports entering text directly from supported braille displays. As for categorizing which displays supports input, we can take a look at documentation for these displays, or send an email to driver writers of these displays seeking help from them as well (mostly for identifying which models supports braille entry and testing this feature).bb
@nvaccessAuto

Comment 55 by nvdakor on 2013-01-09 20:31
Follow-up:
The ones with braille entry functionality are (as far as I know):

  • BrailleNote family.
  • Braille Sense family and Braille Edge.
  • Brailliant BI/B.
  • Refreshabraille 18.
  • Focus series.
  • Alva BC640/680. These have one thing in common: they have full braille keyboard (including dots 7-8 and space bar). Thanks.
@nvaccessAuto

Comment 56 by ragb (in reply to comment 54) on 2013-01-09 21:07
Replying to nvdakor:

Hi,

Testing the updated BN driver. Works flawlessly except only six dot input

is supported (which I understand).

What table are you using? Here I can use 8 dot input (with english and portuguese), except some dot combinations the braillenote refuses to send at all.

As for describing this functionality, I agree that it should be done at the top of the user guide. We can say something like:

  • Supports entering text directly from supported braille displays.

I agree. It's not a very big feature, technically speaking, but for some people this, and anything braille-related, is very very relevant..

@nvaccessAuto

Comment 57 by nvdakor on 2013-01-09 21:19
Hi,
Using 8 dot U.S. braille table as input. Using Apex.

@nvaccessAuto

Comment 58 by jteh (in reply to comment 54) on 2013-01-09 22:01
Replying to nvdakor:

As for describing this functionality, I agree that it should be done at the top of the user guide. We can say something like:

  • Supports entering text directly from supported braille displays.

Imo, we can just merge this into the existing note about support for displays. I'll do this later.

As for categorizing which displays supports input, we can take a look at documentation for these displays, or send an email to driver writers of these displays seeking help from them as well

Changes have to be made to the driver to support input. Aside from the brailliantB and baum drivers, the work needs to be done by the driver developers, as we don't know enough about the drivers and it'll be nearly impossible to do this without a display. alvaBC6 is a special case, since it supports braille input by pretending to be a PC keyboard, so we don't need to do anything and can't even if we wanted to.

@nvaccessAuto

Comment 59 by ruifontes (in reply to comment 55) on 2013-01-09 23:42
At least, almost all Handytech displays are capable of Braille input, like Braillino, Braille Star, Braille Wave, Active Braille and maybe some more.

Rui

Replying to nvdakor:

Follow-up:

The ones with braille entry functionality are (as far as I know):

  • BrailleNote family.

  • Braille Sense family and Braille Edge.

  • Brailliant BI/B.

  • Refreshabraille 18.

  • Focus series.

  • Alva BC640/680.

These have one thing in common: they have full braille keyboard (including dots 7-8 and space bar).

Thanks.

@nvaccessAuto

Comment 60 by jteh (in reply to comment 59) on 2013-01-10 01:01
Replying to ruifontes:

At least, almost all Handytech displays are capable of Braille input, like Braillino, Braille Star, Braille Wave, Active Braille and maybe some more.

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.

@nvaccessAuto

Comment 61 by jteh on 2013-01-10 01:15
What should we do when the user presses a Braille display key in conjunction with dots; e.g. routing+dots? Right now, it will fall through to Braille input handling, but this seems wrong to me. If we don't want this to happen, we'll probably need to make sure drivers don't set the dots or space properties if there are keys other than dots.

@nvaccessAuto

Comment 62 by jteh on 2013-01-10 13:46
Snapshots are now being built for this. I think the gesture API is now stable, so other braille display driver developers can now safely start working on this in their drivers.

@nvaccessAuto

Comment 63 by jteh (in reply to comment 61) on 2013-01-10 13:48
Replying to jteh:

What should we do when the user presses a Braille display key in conjunction with dots; e.g. routing+dots? Right now, it will fall through to Braille input handling, but this seems wrong to me. If we don't want this to happen, we'll probably need to make sure drivers don't set the dots or space properties if there are keys other than dots.

I've done this in my implementation for baum and brailliantB. Rui, you'll probably need to check this for freedomScientific and brailleNote.

@nvaccessAuto

Comment 64 by jteh (in reply to comment 52) on 2013-01-11 03:16
Replying to ragb:

I was thinking about documenting it in NVDA features, since the manual also says braille output. Moreover we should state somehow that only computer braille is supported (that can be on the settings dialog though).

Done.

Has backspace and enter should be mapped (in most cases) to dot7 and dot8, I think we should document it in a general section (i.g. not display-specific). That's what I can think would be interesting, but I'm not sure of the proper places to put it.

Hmm. I was imagining dots 7 and 8 would be used for entry of 8 dot braille; e.g. capitals in English computer braille. That said, we do need bindings for backspace and enter. When needed, we can create a top level Braille Input section, probably above Configuring NVDA.

@nvaccessAuto

Comment 65 by nvdakor on 2013-01-11 07:41
Hi,
As for BN problem: I think I figured out why: when you type text using 1-2-3-4-5-6, NvDA treats them as input keys. However, anything with dots 7-8 is not recognized by NVDA as braille input. This was when using U.S. 8 dot computer braille.
Steps to reproduce:
1. You should have BN as braille display under NvDA.
2. Enter input help mode.
3. Enter six-dot combinations such as 1245 (g), 156 (colon) and so forth. NvDA anounces that it is used for braille input after dot announcement.
4. Enter SPACE with dot 7 combos such as 1-70space (cap A), 4-7-space (at sign) and so on. NvDA does announce dot patterns and stops there. In normal usage, NvDA should announce that it enters text via braille input. This happens with dot 8 combos as well.
System specs: BrailleNote Apex, KeySoft's braille entry set to 8 dot computer braille, NVDA=braileinput:5676, connected via USB, OS=Win8.
Thanks.

@nvaccessAuto

Comment 66 by ragb (in reply to comment 63) on 2013-01-11 19:10
Replying to jteh:

Replying to jteh:

I've done this in my implementation for baum and brailliantB. Rui, you'll probably need to check this for freedomScientific and brailleNote.

Done for the fs driver in change set:brailleInput,5680. It's not needed for the braillenote since the protocol sends different tags for dots, thunb keys and routing buttons, and so does not allow for problematic combinations.

@nvaccessAuto

Comment 67 by ragb (in reply to comment 65) on 2013-01-11 20:20
Replying to nvdakor:

Hi,

As for BN problem: I think I figured out why: when you type text using 1-2-3-4-5-6, NvDA treats them as input keys. However, anything with dots 7-8 is not recognized by NVDA as braille input. This was when using U.S. 8 dot computer braille.

Steps to reproduce:

  1. You should have BN as braille display under NvDA.

  2. Enter input help mode.

  3. Enter six-dot combinations such as 1245 (g), 156 (colon) and so forth. NvDA anounces that it is used for braille input after dot announcement.

  4. Enter SPACE with dot 7 combos such as 1-70space (cap A), 4-7-space (at sign) and so on. NvDA does announce dot patterns and stops there. In normal usage, NvDA should announce that it enters text via braille input. This happens with dot 8 combos as well.

System specs: BrailleNote Apex, KeySoft's braille entry set to 8 dot computer braille, NVDA=braileinput:5676, connected via USB, OS=Win8.

Thanks.

space with dots is not mapped to braille input for now. Any reason you expected it?
For at-sign you probably do dot4+dot7, for capital A you do dot1+dot7. Does it not work?

@nvaccessAuto

Comment 68 by nvdakor on 2013-01-17 05:42
Hi,
Tested with BN set to enter 6-dot computer braille (from BN itself, not NVDA). In this mode, under NVDA, when I press any dot combos with dot 7 or 8, NVDA says it also found space as part of input. For instance, when I tell Apex to use 6 dot computer braille and after I enter terminal mode, I enter input help mode on NVDA. Then I press dots 4-7, for instance. NVDA says "space+do7+D4." Similarly, when I press dots 1-7 (with no space), NVDA detects that space has also been pressed (NVDA announces space+d7+d1 and stops there). This is with Apex. So I guess whenever a user enters dot 7 or 8 with other dot combos, we may also need to assume that a space has been entered, which means we cannot assign NVDA functions to use dot 7/8. As you said, it is not a good idea to assign space+dots 1/2/3/4/5/6 as input keys - only dots 7-8 plus 1/2/3/4/5/6. Hope this makes sense. Thanks.

@nvaccessAuto

Comment 69 by nvdakor on 2013-01-17 07:10
Hi,
Just took a look at braillenote.py in brailleInput branch. I think the problem of BN not allowing full eight dot entry could be solved if we put another dot condition from line 295 onwards (where dot inputs are processed):
// Using mixture of C++ and Py style syntax:
```elif dots is not None
if dots += D7+space self.dots = dots+d7; // To handle cases like 17.
else if dots += d8+space self.dots = dots+d8 // Handle certain dots combos with dot 8.
else if dots += d7+d8+space self.dots = dots+d7+d8 // To handle things like 1278.
// Note that the last case is rarely invoked directly from terminal, as some letters are assigned to switching tasks command on BN.
endif

This illustrates the problem described above - that of BN inserting space dot whenever dot combos with dots 7 or 8 is pressed. Thanks.
else self.dots = dots;





@nvaccessAuto

Comment 70 by aliminator on 2013-01-17 10:27
There seems to be one problem with the base implementation.
NVDA 5681 from BrailleINput branch and the qwerty global plugin is used.
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: ⠓⠑⠇⠇⠕ ⠺⠕⠗⠇⠙

When U.S. braille table is selected (both input and output) everything works as expected.

@nvaccessAuto

Comment 71 by jteh on 2013-01-17 11:09
This is a problem with some liblouis tables. Looking briefly, I believe this might be fixed in a later version of liblouis.

@nvaccessAuto

Comment 72 by ragb (in reply to comment 68) on 2013-01-17 11:27
Replying to nvdakor:

Hi,

Tested with BN set to enter 6-dot computer braille (from BN itself, not NVDA). In this mode, under NVDA, when I press any dot combos with dot 7 or 8, NVDA says it also found space as part of input. For instance, when I tell Apex to use 6 dot computer braille and after I enter terminal mode, I enter input help mode on NVDA. Then I press dots 4-7, for instance.

Does this happen when you define the braillenote to use 8 dot computer braille input?

@nvaccessAuto

Comment 73 by nvdakor on 2013-01-18 06:55
Hi,hen I tell BN itself to use 8 dot computer braille, I have to press space along with any dot combo plus dot 7 and/or 8 in order for NVDA to see that I pressed dot 7 or 8. Thanks.

@nvaccessAuto

Comment 74 by ragb (in reply to comment 73) on 2013-01-18 13:29
Replying to nvdakor:

Hi,hen I tell BN itself to use 8 dot computer braille, I have to press space along with any dot combo plus dot 7 and/or 8 in order for NVDA to see that I pressed dot 7 or 8. Thanks.

So it seems apex is sending different values then classic braillenote... If you see the _dispatch method on the driver class you'll see that I make some tests due to its bugginess, but here if I press dot8 or dot7 with any other dots they are reported, with no space at all. Only dot7 or dot8 alone report a space.

@nvaccessAuto

Comment 75 by nvdakor on 2013-01-18 18:50
Hi,
I just sent an email to one of the HumanWare staff in charge of braille products. I told him improvements to NvDA and braille support, as well as explained eight dot entry issue in terminal mode on Apex. I think, at this point, I propose that we move conversations on BN to a new ticket so other issues with computer braille entry can be discussed here

@nvaccessAuto

Comment 76 by jteh on 2013-01-24 05:13
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.

@nvaccessAuto

Comment 77 by halim on 2013-01-24 12:44
Looked into braillenote driver to get an idea howto implement brailleinput support for papenmeier Braillex Trio.
My questions aqre:

  • does the braille note driver work for you without sorting of the space+dx stuff? eg. d1+d2+space != space+d1+d2
  • The baum brailledriver defines a command and maps it in gesturemap to kb:command. It doesn't use dot patterns for commands! Which implementation should be used/prefered?
@nvaccessAuto

Comment 78 by jteh on 2013-01-24 13:21
@halim: I'm not sure what you mean about the baum driver mapping to commands. The only kb bindings are for the arrow keys on the display itself. Note that d1, d2, etc. aren't Braille dots, despite the name. The Braille dots are b1, b2, etc.

All you need to do is inherit from brailleInput.BrailleInputGesture (as well as the existing inheritance from braille.BrailleDisplayGesture). If anything other than dots or space are being pressed, you must not set self.dots or self.space. If dots are being pressed, set self.dots accordingly; e.g. set bit 1 for dot 1, bit 2 for dot 2, etc. If space is being pressed, set self.space to True.

@nvaccessAuto

Comment 79 by halim on 2013-01-24 13:45
the baum driver was a bad example :-(.

Well my other question is:
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.
Does this code work for braillenote without sorting the keys?

I.ll release the new Papenmeier driver version after merge brailleinput to main.
The gesture map needs to be updated to provide same functionality for Trio like in brxcom.

@nvaccessAuto

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.

@nvaccessAuto

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.

@nvaccessAuto

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

@nvaccessAuto

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.

@nvaccessAuto

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 :-).

@nvaccessAuto

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.

@nvaccessAuto

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?

@nvaccessAuto

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
...

@nvaccessAuto

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.

@nvaccessAuto

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.

@nvaccessAuto

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.

@nvaccessAuto

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.
@nvaccessAuto

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.

@nvaccessAuto

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

@nvaccessAuto

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 :).

@nvaccessAuto

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. :)

@nvaccessAuto

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.

@nvaccessAuto

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.

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