Re: Gnopernicus Sending Output to Serial Device Crashes Hardware Synthesizer

[Peter Korn <Peter Korn Sun COM>]

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