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

[Nicolas Pitre]

On Thu, 25 Jan 2007, Klaus Knopper wrote:

> On Thu, Jan 25, 2007 at 03:02:37PM -0500, Nicolas Pitre wrote:
> > On Thu, 25 Jan 2007, Klaus Knopper wrote:
> > 
> > > Which "other speech-based screen readers that do the job well" are you
> > > referring to? Everything I tested was not in the least way sufficient
> > > for a computer beginner, and didn't work well with either braille or
> > > software sound synthesizers. (yasr, brass, speakup, ...)
> > 
> > Then why not improving on an existing solution instead of duplicating 
> > that work again?
> 
> That's what I was trying to accomplish: actively helping to improve an
> existing solution, namely brltty, to be a good replacement for sbl.

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.

> > You say that "only sbl as both" but this is something that does not have 
> > to be in the same package.  Why do you think that full speech support 
> > and full braille support has to be in the same screen reader?
> 
> Because it makes sense?

In my opinion it does not.  Or rather, it makes more sense to keep them 
separate.

> > The Unix philosophy is to have small tools that do one thing but that do 
> > it well, and then use those tools together.  Not to have a giant 
> > application that tries to do everything and that no one understants 
> > fully anymore.
> 
> Right, I always wondered why "ls" has so many options. There should
> really be 100 programs with NO options instead, that can then be
> combined on the command line, in order to do the same thing as
> ls -lart ...  ;-)

You aren't serious, are you?

ls does one thing: list directory content.  The many options are only 
ways to customize the listing.

What would be bad is to have ls+mv+rm+mkdir+rmdir+touch+find+file+cat 
etc. in the same command.

[ before someone ask: no, busybox doesn't make them the same command ]

> Kidding apart, if it's the common opinion here that brltty should NOT
> have support for keyboard-based navigation and support for communication
> with different speech synhesizers as an add-on, I can as well continue
> to rewrite sbl, rather than going into endless discussions about why
> brltty is not a screenreader or similar.

- keyboard based navigation could be useful in brltty independently of 
  speech.

- brltty already communicates with different speech synthesizers ... as 
  an *add-on*.

And I'm sure you know all that already.

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

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.

And a screen reader for speech may not pretend to do the same thing as 
what brltty does.

And users should be able to choose the speech solution they want 
_independently_ of the braille solution they want.  Artificially tying 
them together does not benefit anyone.

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'm sure if you go that route you'll find it 
easier to proceed.


Nicolas