Re: Console-based applications
On Fri, Feb 16, 2007 at 09:28:28PM -0600, John Heim wrote:
> From: "Jason White" <jasonw@ariel.its.unimelb.edu.au>
>
> >In my case, I don't need any Web sites that rely on Javascript and DOM
> >support, so Elinks, Lynx, Emacs/W3, etc., are all just fine.
>
> Right. But that wasn't really the question. The question was why would a
> blind person want access to a graphical user interface. I guess the
> question itself doesn't really apply to you.
Correct. And of course, with software such as MOzilla and the accessibility
work surrounding it, they aren't so much providing access to the graphical
user interface as providing access to the document itself via appropriate
API's.
>
> >Right now, it depends on what you want to do. But eventually, support for
> >>character browsers, email programs, spreadsheets, and word processors
> >>will
> >>be dropped. You'll still be running your linux servers in character mode
> >>but that's about all you'll be able to do.
> >
> >I disagree with the above. Console-based applications (especially e-mail
> >software) are still under active development, and they'll be around for as
> >long as there are people who want them sufficiently to contribute to their
> >ongoing improvement and maintenance. That's one of the advantages of free
> >software.
>
> Maybe I'm out of touch but is there now a character based browser that
> fully supports javascript? It seems to me that if there is this big
> developer base out there, that would be the first thing they'd fix. And
> even if someone did get around to it eventually, it took a long, long time.
> I know, for example, that emacs-w3 and emacs-w3m don't support javascript.
> That was just mentioned on the emacspeak list today. So there is no
> javascript support in the browsers for emacspeak. And the guy who wrote
> emacspeak works for google.
Elinks supports Javascript. What it currently doesn't support are all of the
DOM and associated API's that can be found in, say, Mozilla. This isn't
unusual, since there are very few implementations of those in existence
(Mozilla, MSIE, Opera and KHTML are the only ones I know of). If you put
together all of the relevant Web standards - XHTML, CSS,
Ecmascript/Javascript, DOM, SVG, MathML, etc., all of this makes for a truly
enormous implementation challenge, which places Web browsers in a class of
their own. Making client-side scripting accessible is still problematic, which
is why there are evolving standards in that area that Mozilla is the first to
implement. Now, writing an e-mail client, news reader, chat
application, etc., requires fewer developer resources, which is why there are
so many more options - including text-based ones - in those areas. The Web is
the big exception precisely because of there being so many standards involved,
and the enormous development resources this demands.
>
> >use word processors. Instead, they write their documents in a text editor
> >such
> >as Vi or Emacs, in a format such as LaTeX or Docbook XML. Typesetting
> >software
> >is then used to prepare Postscript, or more typically these days, PDF
> >output
> >for printing; and the very same source files can be used to generate HTML
> >and
> >other formats as well.
>
> Well, I am not willing to accept your assertion that that is typical. But
> it's not really even to the point. First of all, the process you're
> describing is inefficient and takes more technical knowledge than a lot of
> people have. I work for the Math Department at the University of Wisconsin
> and even the secretaries around here use LaTEX. But people who actually
> know how to *write* LaTEX are few and far between. They all use wysiwyg
> editors. I'm not saying that a lot of folks aren't fine coding every
> character of their math term papers in LaTEX in vi. But a lot of people
> aren't okay with that. And that is why blind linux users need access to a
> Gui.
What you mention is really a problem of education. LaTeX is fairly
straightforward to use, for example, unless you have to make significant
modifications to the typeset output, which really require the skills of a
typographer and knowledge of TeX programming that many LaTeX users don't have
and don't need. There is no reason why I would want to use a WYSIWYG editor
when I can't see the output, and I lose direct access to the markup codes that
specify the structure and control the presentation of my document. If I want
menus and templates to help with the entry of LaTeX code so I don't have to
remember all the commands, that's available with Auctex under Emacs or the Vim
LaTeX extension. If I want a particular layout effect that isn't the default
then there's usually a package in the LaTeX distribution that will solve the
problem.
Thus I claim that there is no benefit in having access to a GUI in this area,
unless you need to write MS-Word files and RTF, HTML and PDF wouldn't be
adequate alternatives. LaTeX is better than a word processor, especially when
working in a non-visual modality. In fact, there are ways of running
OpenOffice in non-GUI mode to do document conversions, but I haven't tried it
myself.
>
> Furthermore, if in your job, you've never had anyone email you a Word
> document or an Excell spreadsheet, you should consider yourself lucky.
I'm unlucky in that respect, but piping it to wvHtml in the case of a Word
document, or xl2html in the case of an XL spreadsheet, solves that problem.
The output is a straightforward HTML document that can be read in any browser.
This is all likely to get easier with increased adoption of ODF and Microsoft
OpenXML office formats, for which writing converters doesn't involve
deciphering an obscure binary format.
So here's my conclusion: access to GUI-based applications is not necessary,
but it's "nice to have", because there are cases in which the most
full-featured and sophisticated tools for the job happen to be GUI-based
programs. However, quality text-based tools are available for most purposes,
and often the conventional Unix approach is superior to the office suites and
other heavily GUI-oriented solutions that come from the non-Unix world. In
Unix, Eric Raymond argues, the GUI is often added at the end; the core of the
tool is textual and often command-line oriented. This is why the greatest
benefit comes from mastering those textual tools, and why access to a GUI in
Unix and Linux, while desirable for certain applications such as the Web,
really isn't necessary.
Reply to: