GNOME Bugzilla – Bug 166064
speech doesn't keep up with terminal output
Last modified: 2005-02-03 16:45:33 UTC
Using nightly build running gnopernicus 0.10.0 and gnome-terminal 2.6.1 - Start up gnopernicus with speech enabled. - Start up a terminal. - Type ps -ef |grep more. Notice that speech goes to the effort of announcing every character. This would be good, only for the fact that (if you can type more than 10 words a minute) once you get to the 'more' part of the command, speech is still reporting " -, e, f, space,". The user has to wait until speech catches up, if they want to hear the last few characters they typed. The terminal output should behave like gedit, where each character is interrupted by the next. If the user desires to hear each character, then they type slower.
should we re-title this bug "gnopernicus speech-by-character doesn't interrupt itself" ?
You could do that, although the optimal behaviour would be for gnopernicus speech not to repeat itself, but to annouce everything and still keep up with the user's input. Also, keep in mind that this bug only appears to exist with gnome-terminal.
I am not sure I follow what you are suggesting, regarding behavior. Are you saying this isn't a problem with, for instance. gedit?
The expected behavior for gnopernicus with terminal is to report all the output. Please see bug 157786.
when navigating by character, or speaking one character at a time, you cannot report all the output; interruption is the desired behavior in most cases.
This problem does not affect gedit in the build that I tested. I am only able to reproduce this problem in gnome-terminal. In response to comment #4, gnopernicus does report all the ouput, if it is given enough time to. If the user presses the keys very slowly, then each character will be read out. I believe that the expected behaviour of gnopernicus speech is also to deliver information on time. This bug is most apparant when typing in commands but it is also present when the result of a command is reported (eg. ls or ps -ef). If the user wanted to hear all the ouput then they would listen. However, if the user has heard enough and wants to type another command then he/she will have to press the <shutup> key, in order for speech to catch up.
John: Are you saying that the speech latency is too high? It's still unclear from the descriptions what is really happenning, and what you expect. I believe that the intended behavior is for speech to get interrupted by these keystrokes, not queued, so you should not expect to hear all output if you type fast.
For gnome-terminal, keystrokes are queued and they should be interrupted, as they are for gedit. If this happened, then this bug could be closed. That would be acceptable behavioiur but still not optimal because users still get minimal feedback when they type fast.
This behavior was changed (behavior of terminals) in order to ensure that terminal output from commands didn't self-interrupt.
The agreed way to fix this is to shut-up speech whenever an alphanumeric key is pressed by the user. That requires XEvIE. Note though, that the current behavior is an anticipateble side effect of a fix for another problem with terminal.
John: we cannot address this bug without regressing the behavior of terminal command output (157786). I propose we close as WONTFIX, though we should revisit the issue once we have XEvIE available on all platforms and implement a new speech interruption architecture (RFE 166182).