Maintaining speechd-up (reading long program outputs)

[Klaus Knopper]

Hi,

On Mon, Jul 19, 2010 at 02:49:32PM -0400, Trevor Saunders wrote:
> HI,
> 
> On Mon, Jul 19, 2010 at 08:10:01PM +0200, Halim Sahin wrote:
> > Hi,
> > On Mo, Jul 19, 2010 at 10:06:32 -0700, Bill Cox wrote:
> > > I only use speech and magnification, so I can't say with authority
> > > anything about Braille.  However, SBL seems Braille-optimized to me in
> > > the way it does cut/paste, and the way it doesn't queue speech to be
> > > read when you issue commands like 'ls'.  Multiple Vinux users have
> > > stated that they will stick with speakup until at least these two
> > > issues are resolved, and my straw poll of blind Vinux users is in
> > > favor of keeping speakup as the default screen reader.  I have
> > > included SBL in the repositories, so users can install them with
> > > apt-get, and I've patched the cut/paste command, but I haven't figured
> > > out yet how to queue speech.
> > 
> > Doing things in kernelspace is afaik the reason for things done in 
> > speakup.
> 
> the *point* of speakup is that it is in kernel mode, which has plenty
> of issues, but also can be really useful.

Running a speech synthesizer early in the boot process is surely
practical, however, the earliest point to do this would probably be a
speech-enabled virtual machine where you even have a talking BIOS setup.
But this is a different topic. Talking about enduser applications now,
that need speech to be available at login or console/desktop startup
time, for which I found that SBL currently gives the best configuration
options and profile handling, with and without braille device.

> > This is also the reason why sbl has many commands for screenreview.
> > BTW.: ls -1 |wc -l in my home gives me
> > 273 files.
> > so I am not able to think of an useful usecase for reading screenchanges
> > automaticaly.
> > If I type ls -1 the pc will read 273 filenames.

I already tried this with a catch-and-read perl interface, but reading
long texts _should_ really be interruptible, including discard of all
remaining text in the speech queue, otherwise it is very annoying and
frequent reason for a coffee break. If I type ls -l in my home
directory, I get 899 long lines of text. You could argue that, I'm a
file system messy, but I surely would find it practical to be able to
browse long command outputs without piping through less. This is
something that's missing in SBL, but on the other hand, not easy to
implement. Since the console buffer is limited, the text may scroll too
fast in order for the screenreader to catch it entirely. A kernel hook
for console print would be needed. A compromise would be just
implementing to read ALL of the changes between the last screen catched,
and the current snapshot, possibly losing anything that was more than a
page of text which had not been read yet.

> come on, having things read as they are printed is obviously useful,

A VERY useful application I could think of, are chat clients such as
irssi or centericq. Currently, I'm using an irssi perl plugin that reads
the text sent by a user in its entity, independent from the screen
reader that just keeps monitoring the input line where I type. Works
well, but speech output is not interruptible since the perl plugin is
not aware of the screenreader navigation, and vice versa.

> is there cases when redirection to a pager may be a better idea sure,
> but a lot of the time its useful.

Maybe a kind of "SBL pager builtin" would be useful, that is able to
cache and read multiple changed lines. That would also allow
multiple-line texts with attribute cursor markings to be read entirely.

> > > However, I feel SBL can easily be modified to be more speech-centric,
> > > perhaps with a mode toggle key to switch behavior.  I think SBL is
> > > fairly well written code, is to read and modify, and I like how it
> > > integrates in the consoles with uinput, and doesn't do anything in
> > > kernel space.  I like the application specific keybindings, and the
> > > simplicity of configuration.  I also like how SBL is separated from
> > > uinput.  A project I am interested in looking into is somehow gluing
> > > SBL into gnome-terminal so that we can have the same screen reader in
> > > both the consoles and gnome-terminal.
> > 
> > 
> > Thx, Patches welcome :-).
> 
> yasr can already do this, I've considered maintaining it more
> actively, and infact plan to since mgorse doesn't seem to be working
> on it, but since its working fine for me, I haven't had much urgency
> to work on that particular project.
> 
> > > Long term I see SBL as the best current platform to build what we
> > > need, but it can't replace speakup as the default screen reader in
> > > it's current state.  I would welcome being proven wrong, though!  If
> > > you could work with the Vinux community to satisfy the concerns of
> > > current speakup users, we may be able to make the switch.

SBL is the default screenreader (including loose interfacing to orca) in
Knoppix. Brltty lacked support of keyboard-only navigation at
that time.

Now, if we could get a builtin multiple-line vcsa-diff pager, it would
be even better... ;-)

Regards
-Klaus