Maintaining speechd-up

[Bill Cox]

Hi, Halim.

On Mon, Jul 19, 2010 at 8:18 AM, Halim Sahin <halim.sahin at t-online.de> wrote:
> @Bill:
> Sbl is used here since 1999 and it has speech support since 2002.
> I am using it for my complete work in the linuxconsole.
> When you say it works best ?only for brailleusers only this will be simply 
> wrong.
> I know many users they are using it in speech-only setups, and on their
> netbooks.
>
> Sure it can be improoved in some points but it has much better
> attribute handling than speakup and is the only sr for using ncurses
> apps.

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.

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.

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.

> @Hynek:
> Integrating console screenreaders in such session tools is not possible!
> People who push these technologies are not using screenreaders and don't
> care about their needs!
> There are ?many problems to solve when the sr is running as root.
> It doesn't improove userexperience but makes things more complex.

Longer term, I believe it is possible to include session integration
in the consoles in a screen reader compatible way that works with the
login prompt and works reliably throughout the system.  We'll be able
to run PulseAudio in user mode, as well as speech-dispatcher/opentts.
However, it does not work today!  Every system that forces session
integration on the consoles currently breaks accessibility!

I understand how the pulseaudio developers are able to ignore the
needs of blind users without feeling guilty.  Blind Linux users are
quite rare, and there are work-arounds.  However, speech-dispatcher
users are typically blind, and working with the consoles is core
functionality.

> It's not enough to say: "plain console logins should really go away".
> Plain consolelogins are great, stable, well tested and very comfortable.

This is especially true for the blind!  If we lose the consoles, many
blind Linux programmers will give up and switch to Windows.

Bill