GNOME Bugzilla – Bug 170551
speech doesn't always interrupt itself
Last modified: 2005-05-16 09:41:47 UTC
Distribution/Version: JDS Rel3 B30 Using gnopernicus 0.10.4 - Open gnopernicus with speech enabled. - Navigate to Preferences->Desktop Preferences->Display->Screen Resolution Notice that tabbing between one combobox and another, speech sometimes has a tendency to finish off what it was saying about the previously selected combobox. This means that the user has to wait to hear output for the newly selected combobox. This can be seen in many places and not just with comboboxes.
The problem here is that context-switched events are sent to speech as uninterruptible. Because of that, a new event of this kind never interrupts the previous.
Created attachment 38883 [details] [review] proposed patch
Comment on attachment 38883 [details] [review] proposed patch > { > SRObjectRoles role; > sro_get_role (obj, &role, SR_INDEX_CONTAINER); >- if (srl_is_object_focused (obj) || strcmp (reason, "present") == 0 || >- strcmp (reason, "object:context-switched") == 0) >+ if (srl_is_object_focused (obj) || strcmp (reason, "present") == 0) Removing the second line above, without replacing it, changes the logic in a way that doesn't seem to have anything to do with this bug report. Why was it removed? Note that previously, "object:context-switched" events would sometimes result in output in this block, but in the new patched version, they can not. > { > if (role == SR_ROLE_STATUS_BAR && strcmp (reason , "focus:") == 0) > src_speech_send_chunk (txt, SRC_SPEECH_PRIORITY_WARNING, TRUE); >@@ -394,7 +393,7 @@
Now, the context-switched belongs to window events class (see srl_check_context_changed). So, the code removed is never reached.
please commit
Comment on attachment 38883 [details] [review] proposed patch Patch committed on cvs head.
Dublin QA reports that this bug is not fixed by the patch above.
In the past, gnopernicus was insisting to speak all context-changed events. Now it is insisting to speak the last. This can not be change. This request (to shut up the context when user moves to another object by hitting the keyboard) is bug #134845. The explanation is: When user moves to another object, gnopernicus detects if the object is in same "context" as previous. If yes, only the new object is reported[1]. If no, a context-changed event is reported followed by a focus event (focus events have lower priority that context-changed)[2]. If user moves to a new object while the context is reported, a new focus event is generated (same case as [1]). But, because it has a lower priority, it can not interrupt the speech.
then the interruption algorithm needs to be changed, or when switching from a context, gnopernicus must explicitly shut up the utterances that are already in the queue. This really does require a fix, it's failing our basic sanity tests.
Same (at least a kind of) behavior is present for gnome-terminal. Because the request is to concatenate all the texts inserted (a result of a user command may generate more text-insert events), after command has finished and user starts to type, gnopernicus will continue to speak the command output. After finishing it, the text inserted by typing will be spoken. Here, the behavior is accepted, user has to press shut up key to stop the speech. The real problem is that an user command may generate more than one event. Same sequence of events can be obtained also as result of more than one user actions. Because gnopernicus doesn't listen the entire keyboard (see bug #163793 where is a patch which does that) there is no chance to distinguish between those 2 cases only from events flow. It has no idea that user has pressed a key.
The only solution I see is to shut up speech before presenting the second event after a context-switched event. This patch _may_ have side-effect. I don't have one in my mind, but I am not 100% confident it doesn't change behavior in other cases too.
Created attachment 46080 [details] [review] proposed patch
John, we need for you to describe in detail the scenario which is still failing.
Remus: I think that speech should always shut up after a context-switched event. John says the problem he's reporting is a regression, so we need to identify which gnopernicus patch made the problem worse.
Remus: We discussed this bug at length on Monday, and proposed a solution there. What is the status of the patch?
Remus - your patch in #12 looks good to me! Please proceed with it.
Comment on attachment 46080 [details] [review] proposed patch Patch committed on head.
thanks Remus, I agree that the patch in #12 is good. I forgot that it incorporated our suggestions, sorry :-)