Hi.
On Mon, Feb 14, 2005 at 02:05:28PM +0000, Bill Haneman wrote:
> Hi:
>
> Kenny said 'I have not enabled braille in gnopernicus', but the bug
> report seems to indicate that 'screen reader' may be been enabled from the
> 'Desktop Preferences->Accessibility->Assistive Technology Support' dialog.
> This dialog turns on both gnopernicus speech and braille.
>
> Kenny, can you run this command to confirm that gnopernicus braille is
> turned on, as I suspect it is?
>
> gconftool-2 -g /apps/gnopernicus/srcore/br_active
>
Yep, it returns "true and my hardware synth is now trashed.
For the record: I configured my console screan reader to use software speech
through speech-dispatcher or I couldn't run this test.
> I am suspecting that it will return 'true'. If it does, please try
> turning it off with
>
> gconftool-2 -s -t bool /apps/gnopernicus/srcore/br_active false
>
That set the key back to false. It required power cycling the synth and
rebooting the system to allow my console screen reader to use the synth
again.
> And see if this solves your problem. If you still need braille, you
> should be able to configure it to use the correct serial port from the
> gnopernicus GUI, once you've got speech working with the above fix.
>
> I'll ask for more details in the bug report, but since you are having
> some problems accessing bugzilla I will ask here - please also report
> the result of
>
> gconftool-2 -R /apps/gnopernicus/braille
>
This produced a lot of output. I ran the command after I had disabled
braille and rebooted the system. Below is the output from the command.
brldev_6_ID = ALVA340
fill_char = ##
brldev_0_ID = VARIO20
cursor_style = underline
brldev_15_ID = HTBS8
port_no = 1
position = 2
brldev_7_ID = ALVA34d
optical = 0
brldev_1_ID = VARIO40
status = CursorPos
brldev_16_ID = HTMB2
brldev_10_ID = ALVA570
brldev_20_ID = ECO40
brldev_default = 0
brldev_8_ID = ALVA380
brldev_2_ID = VARIO80
brldev_10_description = ALVABRAILLE 570
brldev_11_description = BRLTTY's BrlAPI
brldev_17_ID = HTMB4
brldev_11_ID = BRLTTY
brldev_21_ID = ECO80
brldev_9_ID = ALVA544
device = VARIO
brldev_3_ID = DM80P
braille_style = 8
brldev_count = 22
brldev_12_description = HandyTech Braille Wave
brldev_14_description = HandyTech Braille
Star 40
brldev_13_description = HandyTech Braillino
brldev_15_description = HandyTech Braille
Star 80
brldev_16_description = HandyTech Modular
24
brldev_17_description = HandyTech Modular
44
brldev_18_ID = HTMB8
brldev_18_description = HandyTech
Modular 84
brldev_19_description = EcoBraille 20
brldev_0_description = BAUM VARIO -
20 cells
brldev_1_description = BAUM VARIO -
40 cells
brldev_12_ID = HTBRW
brldev_4_ID = INKA
brldev_19_ID = ECO20
brldev_13_ID = HTBL2
brldev_5_description =
ALVABRAILLE 320
brldev_2_description = BAUM
VARIO - 80 cells
brldev_7_description =
ALVABRAILLE 34d
brldev_4_description = BAUM
INKA
brldev_9_description =
ALVABRAILLE 544
brldev_6_description =
ALVABRAILLE 340
brldev_3_description =
BAUM DM80 - 80 cells
brldev_8_description =
ALVABRAILLE 380
brldev_5_ID = ALVA320
attribute = 8
brldev_14_ID = HTBS4
brldev_20_description
= EcoBraille 40
brldev_21_description
= EcoBraille 80
translation_table =
de
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
