GNOME Bugzilla – Bug 609900
Speech page speechdispatcher defaults to zh
Last modified: 2010-09-17 07:33:43 UTC
In Orca speech preferences menu, while switching to from Gnome speech speechdispatcher the default person is 'cantonese-test zh' not the default en. Testcase --------- 1) Orca Speech Perference Page 2) Switch 'Speech System' from Gnome Speech to Speech Dispatcher' 3) The Person settings changes to 'cantonese-test (zh) instead of default.
Created attachment 153753 [details] screenshot of speech menu
joan, this bugs needs your love !
My name's not Joan. :-) And I'm not sure how I can give this bug my love at the moment. Also, please note that I am already notified of Orca bugs and all of their comments so there's no need to add me to the CC list of Orca bugs. Thanks!
What is happening here is that when a new speech system is selected (e.g., switching between GNOME speech and Speech Dispatcher), the last item in the "Person" combobox ends up becoming selected. Given the infrequency in which users switch between speech systems, and the fact that they should review settings before applying them, I'm not sure I see this as a showstopper for 2.30. It is bad, but I don't think it is a showstopper. Therefore, I the fix for this might be postponed to the 2.31.x cycle.
Created attachment 155432 [details] [review] Brute force patch to select the first item in the list Here's a brute force patch that forces the first item to be selected. I don't think it is a good patch because the "Person" value is not retained/restored if the user switches from one speech system and then back to the original one.
Planning spam. Sorry!
Ale, on this one I would like to see if we can get it resolved for 3.0 and also consider including it in a 2.30.3 release because this bug impacts Guadalinex v7.
So i wonder, what would be the correct behavior? 1. Always select default person based on default locale 2. Select the person based on the last selection the user did for the current speech system/synthesizer. For apply 1 maybe the Willie Walker solution would be enough. Reviewing the code it seems that every speech system is responsible to populate the families (the person list) and they explicitly add as first options the person associated to the current locale. For apply 2 remains the question about the default person, if the user did't selected a person for the speech system yet. Once the user did, the question is, must be retained/restored the person selection for every speech system? and, must it be retained/restored between orca preferences sessions?
(In reply to comment #8) > So i wonder, what would be the correct behavior? > > 1. Always select default person based on default locale Always? I don't think so. I think doing so is a reasonable "fall back" plan for when your next suggestion fails. > 2. Select the person based on the last selection the user did for the current > speech system/synthesizer. Personally, I think this makes good sense and would (I assume) be relatively easy/straightforward to do. > For apply 2 remains the question about the default person, if the user did't > selected a person for the speech system yet. Fall back plan time, perhaps? After all, the first item in the list makes more sense than the last. > Once the user did, the question > is, must be retained/restored the person selection for every speech system? There are not that many to store. I'd think you could store the selection for speech system Foo when/if Foo is selected in the combo box. > and, must it be retained/restored between orca preferences sessions? I'm not sure doing so is worth the effort. However, if you feel otherwise, feel free to make that change -- touching base with Juanje as he is actively working on settings Profiles. Thanks!
Created attachment 170139 [details] [review] Retain/Restore user selected families during preferences session The patch supposes no speech servers/synthesizers will be discovered on-the-fly during an orca preferences session (which is the current behavior).
I attach a tentative patch following Joanmarie suggestions. The patch has been generated with git format-patch from git master branch.
Review of attachment 170139 [details] [review]: Overall this looks awesome. Thanks for doing it, Félix! Having given it a spin, there's one additional check that it would seem needs doing, namely: when the user reselects the active server whose settings were not modified during that Preferences session. For instance, if my locale is en_US but the 'Person' saved in my Orca prefs is 'spanish (es)', what should happen if I change away from and then immediately back to the speech system I am currently using? I would expect the Person to be returned to 'spanish (es)', but instead 'default default voice (en)' gets selected (which is a heck of a lot better than Chinese -- and in the case of gnome-speech, Esperanto -- but.... ;-) ). Admittedly this is a bit of an edge case, but I think it's one worth handling.... Thoughts?
Well, it's good enough for this release. Commited at http://git.gnome.org/browse/orca/commit/?id=d6ef18f8d662d0c86440505f498f9235175c5992 Nice work Félix! :-)
Created attachment 170201 [details] [review] Retain user saved family as default Person on preferences dialog Patch filled over orca-2.31.92pre
Thanks for the commit Alejandro! Joanmarie you're right. I attach a patch which adds that behavior.
(In reply to comment #15) > Thanks for the commit Alejandro! > > Joanmarie you're right. I attach a patch which adds that behavior. Nice. Thanks again Félix! :-) Part of me is quite tempted to get this into the stable branch "under the wire" (one minute left until hard code freeze). Well, okay, now we're frozen. However, I branched for 2.32 earlier this evening, so we can commit this to master as far as I'm concerned. I'll let Ale do the honors. (Ale, I do think this is also worth putting back into the stable branch after code freeze is lifted so I'm marking with '2.32.1?')
Comment on attachment 170201 [details] [review] Retain user saved family as default Person on preferences dialog http://git.gnome.org/browse/orca/commit/?id=ed41130516bdc2bebb77684623d97e0c06eeaf46 Closing this bug, and marked for adding to stable branch when unlocking.