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

[Nicolas Pitre]

On Fri, 26 Jan 2007, Klaus Knopper wrote:

> On Thu, Jan 25, 2007 at 09:04:35PM -0500, Nicolas Pitre wrote:
> > Brltty is not an existing solution for speech.  It only uses speech as a 
> > complement to braille.  I was refering to "speech-based screen readers" 
> > here.
> 
> Again, why should I use both, a "braille-based screenreader" and a
> "soundbased screenreader" and possible a "keyboard-based screenreader"
> and many more, if there is a screenreader that has an interface to all
> these services?

Because there is no single screen reader that has an interface to all 
these services.

> If, for example, the braille input device is supposed to interact with the speech
> synthesizer, you will definitely need some kind of connection between
> these.

Sure, and it is called brlapi.

> Apparently, it does make sense to join at least functionalities that are
> frequently used together, in a single program.

Following that logic, this means that vi and gcc should be part of the 
same program because I frequently use both functionalities together.

> So, what were we disagreeing about anyways? I still think that brtlty
> would be a god connector between different input/output options, since
> it already supports some of them, and some others are missing.

It is not brltty's goal to be a god connector.  Its goal is to drive 
braille display hardware and do it well.

> > And I'm sure you know all that already.
> 
> No, I had no experience with brltty, and I was forced to use sbl,
> because brltty needed a braille device that I did not have. ;-)

This means brltty should definitely grow a driver for your braille 
device.

> > > It's just that Mario almost convinced me that it would make sense to
> > > migrate from sbl to brltty in the long term, to have a central point of
> > > support for braille+speech related issues in a lot of different cliet
> > > programs, rather than writing individual and mutual incompatible
> > > programs that all attempt to do the same thing.
> > 
> > This is another distorted statement.  There is no obligation to make 
> > brltty and, say, spktty or any other speech solution mutually 
> > incompatible.
> 
> I misphrased that. The problem arises when two programs try to grab the
> same resource. Have you tried to start sbl and brltty on the same
> console?

I never used sbl. I've often had two brltty instances running on the 
same console though, driving two different braille displays (useful when 
writing a new braille driver).  And I've also used emacspeak and brltty 
together without any problem already.

So I don't see why brltty and sbl couldn't work together on the same 
console given that sbl doesn't prevent brltty from driving the braille 
display of course.

> > It is better to have a client for braille and a client for speech 
> > instead of having a single client that does both.  It ease design, 
> > implementation maintenance and debugging.
> 
> You need a connection between both. I am convinced of that, and most
> people who are currently using sbl for braille AND speech in sync, will
> agree.

Sure, but both don't need to be part of the same executable for that.  
This is Unix we're talking about not DOS.

> brltty is, I think, much better at the braille driver part. sbl is
> currently better at the sound and keyboard-driven softcursor navigation
> part.

Good!  Then sbl can lose its braille support and concentrate on making 
the speech support the best possible.

> > If you want to use brltty but like sbl's speech support then you might 
> > consider simply stripping out braille support from sbl and making sbl 
> > speech support better.
> 
> I can do that. But I tend to believe that brltty is a better candidate
> for extensions.

Good speech support is beyond a simple "extension".  Making brltty able 
to get braille navigation commands from the standard keyboard is indeed 
a nice extension to have.  But throwing full fledged speech support in 
the lot is not wise especially when it can be done more easily in a 
separate program.  This way there is very little possibility for braille 
changes to break speech support, etc..


Nicolas