Development priorities (was Re: forwarded message from Jason White)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


Needless to say, I have no sympathy for some of the arguments that have
been presented here. Hardware (including memory) prices are decreasing.
Most software for Linux these days is being written for (1) the command
line, or (2) the X Window System. Console-based full-screen applications
are constituting a diminishing proportion of total software development
effort, as a review of will show. In terms of screen
reading functionality, the Emacs terminal emulator is more advanced than
any of the primitive screen readers for the Linux console which have so
far been developed, largely due to the significant design and development
effort that has been introduced into Emacspeak and the fragmentation of
the Linux screen reader work into at least four separate programmes:
SVPro, SpeakUp, SCReader and UltraSonix, with only the latter being
reasonably well advanced in terms of configurability and features. The
situation is as follows:

1. Today it is possible to access the shell and text-based applications by
any of the following means: (a) a separate computer acting as a terminal;
(b) the Emacspeak terminal emulator; (c) under development, UltraSonix
with a terminal emulator; (d) under development: the Gnome terminal
emulator; (e) BrlTTY with a braille display (and there is interest in
adding speech output to this software as well).

By contrast, if one wishes to access an X application, the choices are (1)
the Gnome speech server, which is still under development, and (2)
UltraSonix, which requires significant work in order to be ready for
every-day use. It is clear where the access barriers are and where the
priorities should lie, namely with (1) the development of open-source user
software and user interfaces in the manner described in my previous
message, and (2) access to the X environment and its applications. This
becomes all the more important once it is realised that most interactive
software these days is being written for the X Window System.

The objections which have been raised against this approach are: (1)
memory and disk space limitations, which are ultimately a legacy problem
that won't affect most Linux users, especially in the future as X becomes
(indeed it has already become) a standard basis for the user interface;
and (2) dissatisfaction with Emacspeak for spurious reasons such as the
key bindings, which of course can be readily remapped as needed.

[Index of Archives]     [Linux for the Blind]     [Fedora]     [Kernel List]     [Red Hat Install]     [Red Hat Watch List]     [Red Hat Development]     [Gimp]     [Yosemite News]     [Big List of Linux Books]