Re: Gnopernicus Sending Output to Serial Device Crashes Hardware Synthesizer



Hi Bill,

I'm unconvinced of the importance of having Gnopernicus talk to Braille devices by default - at least to talk to Braille devices *directly* by default (vs. via BrlAPI).

While I agree that Braille support on by default makes a lot of sense, the practiciality of it in a world of many Braille displays limits the usefulness. What should the default Braille display be? If Gnopernicus supports (say) a BAUM Vario 40 by default, and you have an ALVA 80-cell display, then Braille being on by default doesn't in fact help you. And the space of Braille display types is rather large; it seems a fair bet that most users won't have the "correct" display for the default. So, having Braille on by default (unless it is BrlAPI) seems of little actual utility.


Peter Korn
Sun Accessibility team


Bill Haneman wrote:
Kenny said (of checking the br_active gconf key:

For the record: I configured my console screan reader to use software speech
through speech-dispatcher or I couldn't run this test.
You don't have to be running GNOME's gui in order to run gconftool-2. I would have thought that power-cycling your synth would have sufficed.

As for the dialog in question - it's not just intended for blind people, it's there for gui-centric testers, admins, and setup folks too. While this may not be true of sysadmins, in general users of hardware synths are in the minority. Certainly we want to try to coexist with hardware synths, so we wish to fix this bug, but I don't think we want to discard gnopernicus' current ability to talk to braille devices in its default configuration. Not all end-users will have console access, or be familiar with it, so various bootstrapping problems remain. The reason for the dialog is to make it possible (and easy) for users to have immediate access to their gui on login, without having to manually start gnopernicus at each login, without feedback. What works well for some users will cause problem for others, and early adopters like yourself help us find those problems.

It would be nice to have reliable plug-and-play of hardware devices for accessibility, but we don't have the necessary capability yet, especially with older devices. And even a hardware probe could have caused a problem for the DECTalk, it seems.

Command-line configuration has a number of drawbacks. While you _can_ use the command line to temporarily set some gnopernicus options, gconf is the preferred mechanism because it is persistent and does not require applications to be launched from consoles or scripts; in the GUI environment, most are not.

- Bill

It's my view that an access technology shouldn't assume anything about a
hardware device existing on a port unless it has been told so by a
command line option.  Gnopernicus deciding to enable braille support and
assuming a braille display is connected to /dev/ttyS0 is like a program
deciding to break a sighted person's moniter.
What's even worse about this behavior, is a blind person will already be
running gnopernicus before they can access this dialog.  This dialog
shouldn't make changes to gnopernicus's config if Gnopernicus is already
running.

         Kenny
------------------------------

_______________________________________________
gnome-accessibility-list mailing list
gnome-accessibility-list gnome org
http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list


End of gnome-accessibility-list Digest, Vol 10, Issue 15
********************************************************

_______________________________________________
gnome-accessibility-list mailing list
gnome-accessibility-list gnome org
http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list





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