GNOME Bugzilla – Bug 157786
No speech for contents from command line
Last modified: 2004-12-22 21:47:04 UTC
When type in Linux Command line (i.e pwd, etc.) from gnome-terminal, speech engine does not announce the content of command line .... When typed in "pwd" .. it does not annouce the the path. Steps: 1. Bring up Gnopernicus 2. Enable speech 3. Bring up Gnome terminal 4. Listen for speech 5. Type in "pwd" 6. Listen for path speech, resulting from command "pwd" No speech about the path at all ... Setups: Gnopernicus : 0.9.16 Gnome Desktop : 2.8.1 Fedora Core 2
t oh I do not think that this is a gnopernicus bug. We are using vte 0.11.11 with patches for bugs #113590, #153405 and #156161 and then this proble does not occur.
I tried to reproduce this bug in Cinnabar 21 using gnopernicus 0.9.16 and vte 0.11.11 (with and without the patches for bugs #113590, #153405 and #156161 - i.e. the behavior was the same). In most situations the result of 'pwd' was spoken by gnopernicus, followed by the presentation of the current prompt. Sometimes, only the presentation of the current prompt was spoken. In both situation the result of 'pwd' was sent to speech. In my oppinion, this is a duplicate of bug #142772.
I am using Cinnabar 22 with gnopernicus from CVS HEAD November 15 and I observed the same behavior described in comment 2.
So we really have two solutions: either always concatenate all speech output from vte, relying on the user to press Shut-Up; or use XEvIE to see the user keystrokes and always shut up any time the user presses a non-Gnopernicus-command key.
Created attachment 33837 [details] [review] proposed patch This patch is not the best solution. A new event handling algorithm in gnopernicus is the best one.
I think the patch could be reduced to one line by using the conditional operator ( a?b:c ) for the last param to speech_send_chunk.
Created attachment 34152 [details] [review] reworked patch (with Bill's suggestion)
In case of presing shut up key, at next text-insert event, gnopernicus speaks older information. This is because when shut up function is called list with items waiting to be spoken is not freed. This bug is obvious when many items with same priority but with non interruptible are sent to speech one after other, like in case of previous patch.
Created attachment 34155 [details] [review] proposed patch for speech issue
Comment on attachment 34155 [details] [review] proposed patch for speech issue looks good - I presume we're agreed that shutting up speech that hasn't yet started being spoken is OK? Even for highest-priority speech? We might consider a small modification to this patch which doesn't remove queued speech with a top priority. This means that in order to stop urgent speech, the user might have to press ShutUp twice, but it means that the first shutup would stop the current speech and purge any non-critical messages, but top priority speech would only be shutup if it was the 'current' thing being spoken. Or is it already the case that such urgent speech would interrupt the current utterance, so the patch would only remove queued "top priority" speech if there were multiple top-priority items in the speech system?
Bill, the real problem of this bug is solved in patch from comment #7. Please review it.
the patch in comment 7 doesn't actually use my suggestion... however it looks OK.
Comment on attachment 34152 [details] [review] reworked patch (with Bill's suggestion) Patch applied to cvs head and gnome-2-8 branch.
Comment on attachment 34155 [details] [review] proposed patch for speech issue Patch applied to cvs head and gnome-2-8 branch.