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

[Klaus Knopper]

On Thu, Jan 25, 2007 at 09:04:35PM -0500, Nicolas Pitre wrote:
> > > 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.

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?

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

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.

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

ls does far more: It has color profiles and sort options that include
the functionaliy of stat, date, sort, and find. So, if you would like
"ls" to follow the Unix "one command for one purpose" idea strctly, it
should be replaced by "echo *".

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

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

Again, ls joins "echo *", "du", "stat", "date", "touch", "find" and
"sort" functionalities, so the "one command, one purpose" is already
broken there.

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

busybox as "one command" is like saying that emacs is just an editor.
I can agree as far as one program should not attempt to solve all
problems that are not even remotely related. ;-)

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

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.

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

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

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

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

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

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

Then please show me a solution, with an arbitrary combination of
different screenreaders, braille drivers, software speech synthesizers
and keyboard sniffers, that does what I was talking about. Maybe I
missed something in the now 2 years of research and development, and
it's already done elsewhere.

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

> I'm sure if you go that route you'll find it 
> easier to proceed.

Have you looked into the sbl code?

-Klaus