[BRLTTY] brltty "keyboard braille device" support (and a few more things)

[Nicolas Pitre]

On Thu, 25 Jan 2007, Mario Lang wrote:

> If we make cut and paste available via the keyboard, we will need
> some way to mark the area, since we do not have routing keys available.
> Speech only use would require some kind of reading cursor anyway,
> that might be used to mark the area in question as well.

Don't you think that once you dive into the reading cursor business it 
then becomes far from trivial implementation wise?

> Regarding the whole keyboard-only issue, to me, it would make
> much sense to add this to BRLTTY for the following reasons:
> 
> * It would be neat to be able to use a laptop for instance temporarily
>   without a braille display connected.  Currently, on linux, thats
>   only possible by using a completely different screen reader like
>   yasr or screader.  This is not exactly comfortable, since
>   the user would need to know how two screen readers work, just
>   for this temporary case...

Either you use speech or you don't.  If you do then you will be 
accustomed to speech commands independently of braille commands already.  
If you don't normally use speech then having full fledged speech support 
into brltty won't be any more comfortable than having a separate screen 
reader.

>   I can think of some concret situations
>   that match this, like:
>   * Your display battery ran out, and you forgot to carry the charger
>     with you.  Some displays (like the HandyTech Braille Star)
>     can not be charged via USB.  If you are using a mobile setup,
>     it is desireable to be able to continue working, instead of being stuck.
>   * A 80 cell display owner might want to use the display with their laptop
>     while at home, and only use speech while being mobile.
> * It would also add a safety net for exceptional situations
>   where you for instance loose your display for some time.  Either
>   because it is being repaired, or you misconfigured something
>   and you are now trying to fix it.  If brltty had a speech-only
>   mode, upon failure to init the display, the user would not
>   be left in a complete void, but could still do something based
>   on speech feedback.

And what exactly is the advantage of having speech support in brltty 
instead of a separate application again? Just start your favorite speech 
driven screen reader in parallel with brltty and activate one or the 
other at your leisure.

> To summarize, for this item, I think we need:
> * A keyboard input module, using the input layer and uinput.
>   I remember we need this anyway for some type of display that does
>   not have keys.
>   Since I've already looked at uinput for the
>   HandyTech external keyboard thingy, I would volunteer to start 
>   implementing this.
> * Some kind of binding config file to configure what keys on the keyboard
>   to bind to what BRL_ command.
>   I think if we use keyboard input, we really need to make
>   this user configurable from the beginning on.

No problem with me so far.

> * A "soft"-cursor, that can be manipulated from the keyboard, and
>   which is used to determine what should be spoken.  This is more or
>   less the same as we have with display window position right now, just
>   think of a 1x1 display.  Move up/down/left/right.  Either speak
>   the line, or char, or word.  Thats basically what other
>   speech based screen readers do.

Then... why just you don't use those other speech based screen readers 
from the start?  This is where I have problems with the whole notion of 
adding more sophisticated speech support into brltty while other 
packages already do the job well and can be used along side with brltty 
anyway.

If anything maybe those other speech based screen readers could use 
brlapi to have some kind of real time braille feedback for spoken text.  
But I really don't get the argument that "things would be so much better 
if brltty had full speech support" since, to me, it would make no 
difference from a separate screen reader running in parallel.  You'd 
have to learn extra function keys in either cases.

But from an implementation and maintenance point of view brltty is best 
without those completely different speech issues especially when they 
can be confined to a separate application just fine.


Nicolas