Support for entry of computer braille via a braille keyboard

nvaccessAuto commented 14 years ago

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 commented 11 years ago

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

nvaccessAuto commented 13 years ago

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 commented 13 years ago

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 commented 13 years ago

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 commented 13 years ago

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

nvaccessAuto commented 13 years ago

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 commented 12 years ago

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 commented 12 years ago

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 commented 12 years ago

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 commented 12 years ago

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

nvaccessAuto commented 12 years ago

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:

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 commented 12 years ago

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 commented 11 years ago

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

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 commented 11 years ago

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:

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.

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

Agreed.

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:

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.

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.

Implement support for devices. :)

Boring part... :).

nvaccessAuto commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

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:

Specific !brailleDisplay gesture.
Generic chord / dots gesture with plain dots (i.g. dot1+dot2).
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:

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.
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 commented 11 years ago

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?

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 commented 11 years ago

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

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 commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

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

nvaccessAuto commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

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.

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)
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 commented 11 years ago

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

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 commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

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:

We should perhaps consider renaming "Translation table" to "Output table" in the GUI so it's clear what it does.
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 commented 11 years ago

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 commented 11 years ago

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.

nvaccess / nvda

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