GNOME Bugzilla – Bug 637778
Orca stops speaking if Escape is pressed after loading certain profiles
Last modified: 2010-12-24 11:11:48 UTC
From José on the Orca list: ----------------------- Hi Joanie and all. Try the following: 1. Activate orca preferences. 2. Load a different profile. 3. Press escape or click the cancel button. In my machine orca freezes. ----------------------- Note: I cannot reproduce this issue. From Halim on the Orca list: ----------------------- On Di, Dez 21, 2010 at 06:24:55 -0200, José Vilmar Estácio de Souza wrote: > 1. Create a new profile and configure it to use a different synthesizer. > 2. Load the new profile. > > After load the new profile, orca doesn't talk using the synth configured > in the new profile. > The synthesizer will be used only after the OK or apply button is clicked. I can confirm this behaviour. It seems that it loads only the synth parameters (rate pitch etc) but does not set the synth. Regarding your freeze when pressing esc after loading a new profile: I can confirm that orca runs but it produces no speech output. My brailledisplay works. If this happens, I can't quit orca with orca+q or enter orca prferences with orca+space. -----------------------
Other details from José on the Orca list: ----------------------- My default profile is configured to use IBMTTS and my eclipse profile is configured to use espeak. If I load a profile and then I press the escape key, orca freezes. ----------------------- Halim also uses different synths at times. This might be where the problem is.
Another way to reproduce the problem. 1. Activate orca preferences. 2. Select the speech page. 3. Press tab until you find the synth combo. 4. Select another synthesizer. 5. press escape. Orca stops to talk.
(In reply to comment #2) > Another way to reproduce the problem. > > 1. Activate orca preferences. > > 2. Select the speech page. > > 3. Press tab until you find the synth combo. > > 4. Select another synthesizer. > > 5. press escape. > > Orca stops to talk. Aha. Interesting. I can reproduce this problem in Orca for gnome 2-30. So it looks like you've found a real bug, but I don't believe it's a profiles bug.
Created attachment 176903 [details] [review] tentative solution to the second reported problem The problem seems to be that the user cancels out of the dialog, we attempt to "clean up" the speech servers. The problem is that we're behaving as if the servers had changed; in actuality, they have not. And they will not until and unless the user presses Apply or OK. By acting as if the servers had changed, we're destroying the wrong server and leaving a non-existent one as the active one. I've removed the "clean up" call so that when the window is cancelled out of, we don't clean up the servers. This may or may not solve other reported issues with speech. Please test.
(In reply to comment #3) > > Orca stops to talk. > > Aha. Interesting. > > I can reproduce this problem in Orca for gnome 2-30. So it looks like you've > found a real bug, but I don't believe it's a profiles bug. I can not reproduce using 2.32.0.
(In reply to comment #4) > Created an attachment (id=176903) [details] [review] > tentative solution to the second reported problem > > The problem seems to be that the user cancels out of the dialog, we attempt to > "clean up" the speech servers. The problem is that we're behaving as if the > servers had changed; in actuality, they have not. And they will not until and > unless the user presses Apply or OK. By acting as if the servers had changed, > we're destroying the wrong server and leaving a non-existent one as the active > one. > > I've removed the "clean up" call so that when the window is cancelled out of, > we don't clean up the servers. > > This may or may not solve other reported issues with speech. > > Please test. It works! Now if I press escape after change the synth or load a new profile, orca does not stop to talk. When I load a new profile, the old synth continues to be used. The patch does not fix this situation.
Comment on attachment 176903 [details] [review] tentative solution to the second reported problem Committed as the fix for the spin-off bug 637865 http://git.gnome.org/browse/orca/commit/?id=f58010a606a772e511532fedd84a5acebfe71590
(In reply to comment #6) > It works! > Now if I press escape after change the synth or load a new profile, orca does > not stop to talk. Yay! > When I load a new profile, the old synth continues to be used. > The patch does not fix this situation. Boo! But thanks for testing it. I will dig deeper. Looks like you found two bugs then, rather than 1. As a result, I spun off your second report into bug 637865 and committed the patch as the fix for it.
> When I load a new profile, the old synth continues to be used. > The patch does not fix this situation. Does the patch I just attached to bug 637667 solve it? <crosses fingers> If it does (I hope! I hope!) what additional issues remain for you with respect to profiles? Thanks!
Adding myself to CC list. Also, question in general about some of these patches. Some of them look like they can easily be applied with a 'git am' but others lack the header (like this one) so I have to do a 'git apply' and make up my own summary/description. Is there any particular reason for the difference in how these get put up? Not complaining, just generally curious. Still learning all the deeper nuances of git.
(In reply to comment #10) > Is there any particular reason for the > difference in how these get put up? When I'm absolutely confident in my patch, I take the time to write out a commit message, commit it to my local branch, and do a git format-patch master before attaching it. When I'm pretty certain it will work, but less confident, I just do a quick git diff and attach it.
p.s. No you don't have to do a 'git apply'. You can do a patch -p1 < foo.patch.
(In reply to comment #9) > > When I load a new profile, the old synth continues to be used. > > The patch does not fix this situation. > > Does the patch I just attached to bug 637667 solve it? <crosses fingers> YES! It works fine. > > If it does (I hope! I hope!) what additional issues remain for you with respect > to profiles? > Until now I found no problems. > Thanks!
I committed a different patch for the fix for bug 637667 which does the same thing as the previous patch and some additional stuff (to solve braille and keybindings). I believe that now all the *loading* issues are resolved. It turns out that something is causing us on occasion to *save* profiles incorrectly (i.e. duplicate items in default and the user-created profile). This makes it seem like we're not loading profiles correctly, when in actuality we are. I've opened bug 637930 for that issue.