Hi Kenny,
I'm glad you are moving toward resolving this with Access Solutions. I think the most critical things are:
1. That the DECTalk Express can be "killed" with a particular sequence of characters sent to it. This is fundamentally a DECTalk Express issue. It doesn't really have anything to do with Gnopnericus. Some other application could have done the same thing.
I have to disagree. I have 3 hardware synths: an old DECtalk express (serial only), a Doubletalk LT, and an Accentsa. Enabling the screen reader option in the assistive technology dialog will crash all 3 of them. In my case, the crash isn't perminent. However, it will cause me to loose access to my text consoles. Gnopernicus and gnome accessibility just isn't good enough yet to provide a blind user access to a Linux system. Until this changes, loosing access to the text console is no different than you suddenly loosing your monitor.
I have 3 text console screen readers installed on this system. All of them are designed in such a way that the Gnopernicus problem doesn't happen.
The point I was trying to make is that in an ideal world a serial synthesizer wouldn't be vulnerable to being "killed" by any stream of bytes sent to it. In a separate thread Mario noted that some serial synthesizers support firmware upgrades via the serial port; perhaps that is what happened here (and when I wrote in this thread yesterday, I had forgotten about this feature).
2. That Gnopernicus by default launches wanting to talk to a particular Braille device, and that this is unexpected by users and can have unintended side effects (such as your rather catastrophic one).
There has been some discussion in this thread about Gnopernicus "probing" the serial port trying to determine which Braille device is connected. In discussions with BAUM engineering earlier today, I don't believe this to be the case. From all that I've seen in this thread and from my own familiarity with Gnopernicus, I believe that #2 above is what happened.
Please explain this more. Gnopernicus is clearly writing to the serial port.
Yes, absolutely it was. The question is why was Gnopernicus writing to the serial port, and under what circumstances. Certainly in your case and Beth's case, you didn't explicitly ask Gnopernicus to write to the serial port!
Please see the discussion of this issue in bugzilla bug #167221: http://bugzilla.gnome.org/show_bug.cgi?id=167221
Further research points the finger to two things that together caused this "killer" stream of characters to be sent from Gnopernicus to your serial port and synthesizer:
a) Telling the GNOME desktop to start the screen reader every time you
log in (in Assistive Technology Preferences Dialog) in turn *explicitly*
wrote to the Gnopernicus gconf user settings telling Gnopernicus to start
with speech *and* with Braille. This is unexpected, unanticipated,
and arguably wrong behavior. b) Gnopernicus, being told to start with Braille (but not which Braille
device or port), assumed a Vario 20 on port 1. This is clearly not
a good assumption to make.The point is that Gnopernicus tried to interact with Braille because it was told to use Braille (by the AT Pref Dialog) and, not knowing what device or port, assumed Vario 20 on port 1 (where the serial synthesizer was connected and unprepared for the strings Gnopernicus sent it).
It has been suggested that Gnopernicus NOT be launchable *initially* from the GUI, but rather that the first launching must instead be from the command line and that the options there then be taken by Gnopernicus and used thereafter. I personally think this is a mistake. Too many magnification users need it to work. We also introduce a significant impediment to localization by having Gnopernicus play a WAV file (rather than immediately default to using speech).
If you're refering to my suggestion about adding a command lin option for braille, then you are misunderstanding what I meant. When I suggest a command line for Gnopernicus, I mean something added to the command typed in the run dialog of Gnome, not a command in a text console.
I'm a bit confused. I believe all of the command line options you can use on the text console can also be used in a run dialog. Can you be more specific?
If by GUI, you mean the assistive technology dialog, then consider adding the following buttons. When "enable screen reader" is checked, the user will be presented with the same dialog you get from option 1 of the main menu of gnopernicus. This will allow a sighted user to configure Gnopernicus corectly. For the blind user who is already running Gnopernicus, this will be anoying, but it should solve the problem of the screen reader trashing other access technology running on the system.
Excellent suggestion. Another variant is to have four check boxes instead of three: "Screen reader speech", "Screen reader Braille", "Magnifier" (or "Screen reader magnification", and "On-screen keyboard".
Personally, I think the appropriate solution is to have Gnopernicus either use only BrlAPI as Braille by default with no command-line options, or to not use Braille at all by default when launched with no command-line options.
This last statement shows you aren't as familiar with Gnopernicus as you think. the current behavior of Gnopernicus when started from a run dialog in Gnome is to start with speech enabled using the Kevin voice of the gnome-speech festival driver. Because there isn't a command line option to start with braille support, users who are deth blind can't get Gnopernicus up and running without help. I believe you could set gconf keys from a text console, but you seem to be trying to discourage the use of text console access.
Your Gnopernicus starts with Kevin from Festival because that is the software TTS engine you have installed. Mine starts with Kevin from FreeTTS because that is the TTS engine I have installed (and Kevin is voice #0). If the only TTS engine on my system was DECtalk (and I had the DECtalk gnome-speech driver), then Gnopernicus find and use that.
To start Gnopernicus with support for Braille use the "-b" option. To explicitly turn off speech, "-S". This overrides the users's gconf settings. You can also explicitly specify a serial port and Braille device on the command line. Below is the output from 'gnopernicus --help', which lists all of the command line options:
%gnopernicus --help Usage: gnopernicus [OPTION...] --load-modules=MODULE1,MODULE2,... Dynamic modules to load
Help options -?, --help Show this help message --usage Display brief usage message
Application options
-d, --default Launch in execution with default
settings
-b, --enable-braille enable braille service
-B, --disable-braille enable braille service
-s, --enable-speech enable speech service
-S, --disable-speech disable speech service
-m, --enable-magnifier enable magnifier service
-M, --disable-magnifier disable magnifier service
-o, --enable-braille-monitor enable braille monitor service
-O, --disable-braille-monitor disable braille monitor service
-l, --login Used at login time
-p, --braille-port=ttyS[1..4] Serial port (ttyS)
-e, --braille-device=DEVICE NAME Braille DeviceGTK+
--gdk-debug=FLAGS Gdk debugging flags to set
--gdk-no-debug=FLAGS Gdk debugging flags to unset
--display=DISPLAY X display to use
--screen=SCREEN X screen to use
--sync Make X calls synchronous
--name=NAME Program name as used by the window
manager
--class=CLASS Program class as used by the window
manager
--gtk-debug=FLAGS Gtk+ debugging flags to set
--gtk-no-debug=FLAGS Gtk+ debugging flags to unset
--g-fatal-warnings Make all warnings fatal
--gtk-module=MODULE Load an additional Gtk moduleBonobo activation Support --oaf-ior-fd=FD File descriptor to print IOR on --oaf-activate-iid=IID IID to activate --oaf-private Prevent registering of server with OAF
GNOME GConf Support
GNOME Library
--disable-sound Disable sound server usage
--enable-sound Enable sound server usage
--espeaker=HOSTNAME:PORT Host:port on which the sound server
to use is running
--version 2.6.0Session management --sm-client-id=ID Specify session management ID --sm-config-prefix=PREFIX Specify prefix of saved configuration --sm-disable Disable connection to session manager
GNOME GUI Library --disable-crash-dialog Disable Crash Dialog
A deaf-blind user might start Gnopernicus thusly:
'gnopernicus -b -p=2 -e=ECO20 -S -M'
to launch Gnopernicus without speech or magnification, and with an ECO Braille 20 on port ttyS2.
Now, having done this once, those settings would be preserved in the user's gconf database, and running 'gnopernicus' alone, without command line arguments, will use those settings (no speech, no magnification, Braille with an ECO Braille 20 on port ttyS2).
Please consider spending more time running Gnome and it's assistive technologys. You really can't beat hands on experience to understand a problem.
I'll go ahead and apologize in advance for that last statement,
Apology accepted.
> but it's
really frustrating when a sighted person running MS Windows posts a
message suggesting a problem with Gnome accessibility that costs me access to my computer isn't really a big deal.
I'm sorry if anything in my message suggested to you that I don't think this is a serious issue. This problem has hit multiple people, and the end-result is catastrophic (at least in one case - with Beth). In addition to ensuring that the GNOME environment is never unfriendly to AT and users of AT, however, I also feel that AT devices should be very robust. Hence my comment that one of the "most critical things" is that the DECtalk can be put into a catatonic state that requires factory intervention. That, too, seems to me to be a bug to be fixed (along with the GNOME and Gnopernicus problems that we've been discussing).
As to my use of Windows to send e-mail... Sigh. My job at Sun requires the use of a Linux system, a Solaris SPARC system, and a Solaris x86/x64 system (for my work on GNOME and Linux and Solaris accessibility), and also a Windows system (for my work on Java accessibility and StarOffice accessibility as exposed via the Java Access Bridge to Windows AT apps). Of these four systems, the first three systems are *frequently* blown away and re-installed with internal Sun builds. Only the Windows OS stays stable (with updates to Java, StarOffice, etc.), and hence is my primary (but not exclusive) e-mail client.
One of the greatest things about switching from MS Windows to Linux for me was finally being able to install and maintain the system without sighted help. In my view, anything that causes me to loose that access is a step backward.
No argument. The key thing for me is to clearly understand what those things are that are causing that loss of access, and then to get them fixed. I am concerned that Gnopernicus was blamed for some things that weren't in fact Gnopernicus errors (e.g. that the desktop AT configuration GUI didn't make clear to the user that it would tell Gnopernicus to use Braille when the user asked for "screenreader").
Regards,
Peter Korn Sun Accessibility team
_______________________________________________ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
