GNOME Bugzilla – Bug 523082
text-setup should not use speech if --disable=speech is used
Last modified: 2008-04-04 20:58:47 UTC
See http://bugzilla.gnome.org/show_bug.cgi?id=522980#c4. The general motivation is that text setup should be allowed to work even if speech is broken or unavailable.
Created attachment 108481 [details] [review] Revision #1. I think this is doing the right thing. Patch not committed yet. Please test.
(In reply to comment #1) > Created an attachment (id=108481) [edit] > Revision #1. > > I think this is doing the right thing. > > Patch not committed yet. Please test. > Tested using "orca -t --disable=speech" from a gnome-terminal and from an xterm. I managed to get it to work once, but every time thereafter, it seems to hang at the "Enable Braille? Enter y or n: " prompt. I'm not sure what's causing the hang, but I recall something with importing gtk and not going into a mainloop being a culprit. Not sure how to resolve this one -- I'm open to your investigation and suggestions.
> I managed to get it to work once, but every time thereafter, it seems > to hang at the "Enable Braille? Enter y or n: " prompt. I can't make this happen. I initially start orca with: $ orca -t -d speech Enable Braille? Enter y or n: y Enable Braille Monitor? Enter y or n: y Setup complete. Press Return to continue. SPEECH OUTPUT: 'Welcome to Orca.' BRAILLE LINE: 'Welcome to Orca.' VISIBLE: 'Welcome to Orca.', cursor=0 BRAILLE LINE: 'orca Application Orca Screen Reader / Magnifier Frame' VISIBLE: 'Orca Screen Reader / Magnifier F', cursor=1 SPEECH OUTPUT: 'Orca Screen Reader / Magnifier frame' BRAILLE LINE: 'orca Application Orca Screen Reader / Magnifier Frame Preferences Button' VISIBLE: 'Preferences Button', cursor=1 SPEECH OUTPUT: '' SPEECH OUTPUT: 'Preferences button' Whilst Orca is running, I go to another terminal window and do exactly the same again. It works fine. No hangs. I've tried it with and without the Orca main window showing. This is with latest Ubuntu Hardy. Can others try this too and provide feedback? Thanks. PS: One thing to note here, is I don't have a braille display attached. Maybe that has something to do with it...
As an experiment, can you please try the following in a gnome-terminal window: bash-3.2$ python Python 2.4.4 (#1, Nov 19 2007, 03:59:24) [C] on sunos5 Type "help", "copyright", "credits" or "license" for more information. >>> import gtk Then, try typing some characters. On my machine, the keyboard is 'frozen' until I kill the python process by closing gnome-terminal window.
$ python Python 2.5.2 (r252:60911, Mar 12 2008, 13:36:25) [GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu4)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import gtk >>> a=1 >>> Works fine for me.
(In reply to comment #5) > Works fine for me. Sounds good then. This might be a Solaris/Linux or GNOME 2.20/2.22 difference (XEvIE?). Given the current lack of text consoles on Solaris, that Solaris generally does a decent job integrating speech/audio, and that users are not likely to disable speech from the text-based setup, I'm OK with checking this into trunk and gnome-2-22 if Joanie and Mike have the same positive "no hang" experience on Ubuntu. Thanks!
Well, I have a positive "no hang" experience both in Ubuntu *and* on Solaris (build 83). I can reproduce what Will experienced in comment #4 (Solaris only). But like Rich I don't have a braille display set up on any of my machines at the moment (it's an old school display and hence just too darn bulky). So I haven't bothered to get the latest brltty, etc. Is there any chance that, as Rich suggested, one's braille setup has something to do with it?
Patch committed to SVN trunk and gnome-2-22 branch. Closing as FIXED. Thanks.