Re: issues with X Window

["L. C. Robinson" <lcr cyberhighway net>]

On Mon, 23 Aug 1999, Paolo Molaro wrote:

<snip> (speaking of X access tools)

> There are two basic requirements: 
> 1) the thing should work with the applications unmodified
> 2) the thing needs access to the application internals
> 
> The first requirement means that our tool should work with an
> application without changes to the application itself.

This sounds like a rather unlikely ideal (which fact you comment on
below).  It seems to me that such a tool is really trying to add
text capability to an app, which a synth can then convert to sound,
with the added restriction that you cannot directly modify the app
itself.   Such an approach will no doubt force the programmer to go
through some rather tortured contortions to get things to work,
with less than optimum results.  This makes sense with proprietary
software, where there is no alternative (and vendors are making
such apps available for linux),  but I wonder if it makes as much
sense with OSS; might it not work better to just contribute patches
to the code base of such apps to make text mode versions possible?
There are already many apps that have text and GUI counterparts
for linux and *nix: this tradition can be encouraged, probably with
much better results than trying to make everything work under the
GUI, which isn't necessary under linux.

> This is not always possible, sometimes an applications needs some
> usability enhancements, but the point is that the tool must be
> external to the application, otherwise you will need to upgrade
> your tool whenever you upgrade the application, keep them in
> sync, have a different tool for every different application and
> so on.

Correct me if I'm wrong, but, if usablity enhancements have been
added, won't they be application specific additions to the screen
reader tool (which will be necessary in most cases)?  If so, won't
you have to upgrade your tool anyway whenever you upgrade or add
applications?  What happens in the M$ world relative to this?
Has it proved to be feasible to make truly application independent
screen reader tools for any GUI environments anyone knows of?
Do such tools have application specific modules or "drivers" with
them?

> This is not going to work in the long run without a general,
> application-independent approach.

It would be nice to believe that such are possible, but can we
consider the extent to which we might be chasing rainbows?  Maybe
other approaches would be easier, cheaper, or work better.  Maybe
applications that are actually built to run in text mode will
ultimately serve the blind community better, and others as well.

Now, I note that that Paolo has made it clear in another message
that text mode apps are better for most uses, and he seems to be
aware of the problems (and understands the programming issues far
better than I): I was just concerned that some posters in this and
related threads seem to have some illusions that GUI speech tools
can be made to solve all access problems, with one clean, sweeping
approach.  Correct me if I'm wrong, but I suspect that even when
such tools sort of work, they will generally be kludgy work
arounds.  In the OSS culture, we can do much better (and already do
so, for most uses).

<programming details snipped>

LCR

-- 
L. C. Robinson
reply to lcr cyberhighway net

People buy MicroShaft for compatibility, but get incompatibility and
instability instead.  This is award winning "innovation".  Find
out how MS holds your data hostage with "The *Lens*"; see
"CyberSnare" at http://www.netaction.org/msoft/cybersnare.html