address@hidden: Re: Maintaining speechd-up (reading long program outputs)]

[Trevor Saunders]

----- Forwarded message from Trevor Saunders <trev.saunders at gmail.com> -----

Date: Mon, 19 Jul 2010 17:42:14 -0400
From: Trevor Saunders <address@hidden>
To: address@hidden
To: Klaus Knopper <speechd at knopper.net>
Subject: Re: Maintaining speechd-up (reading long program outputs)
User-Agent: Mutt/1.5.20 (2009-06-14)

HI,

On Tue, Jul 20, 2010 at 12:47:48AM +0200, Klaus Knopper wrote:
> 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.

sure, but sometimes its nice on real hardware too, I hardly care about speech 
in my vm'
s other than for dev work, I just use qemu / kvm with -curses  so I
don't really see the point when you can read the screen why bother
with a screen reader?  As for a software synth during early boot I
suspect I can do it in the initrd, but haven't tried.

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

fair enough, to be honest I've never really wanted profiles for
particular applications much, yasr just works tm with just about
everything in a pretty reasonable way.

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

again yasr can do this, it has key strokes for stop speaking and don't
speak until a key is pressed.  you could also do this with spd-say to
be a bit more on topic.

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

personally I would want 900 lines broken up, I don't want to read it
all at one shot, which a pager does nicely.  It seems like you are
trying to re invent the pager, it solves the same problem of text
scroling off your screen.

BTW I feel like this sbl approach of capturing the screen at intervals
is rather hacky, how do you pick the times to use as snapshots
from a continuus stream?

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

yeah, yasr does the read messages as they come in and stop when you
navigate already.

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

what is the point of writing your own pager when there are already
perfectly good ones?

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

Personally I feel like both parts of that idea are bad, diffing
arbitrary times in a continum, and embeding a pager in a screen
reader.

It seems like yasr does most of what you actually want already, but
maybe I'm wrong.

Trev

> 
> Regards
> -Klaus

----- End forwarded message -----