GNOME Bugzilla – Bug 111853
"switch to window" -> "switch to: <window label>"
Last modified: 2004-12-22 21:47:04 UTC
the "switch to window" message would be heaps cooler if it said "switch to: <window label>", for example: "switch to terminal" "switch to galeon" "switch to x-chat" Thanks!
This kind of presentation should be present, indeed. I think that due to some priorities that were introduced some time ago, this feature was lost. We will investigate more on this bug and hopefully solve it ;-).
Jeff: Behaviour described by you is already implemented. It is posible not to work for you if you are using festival. Can you tell me what speech driver is installed on your computer?
Using festival, latest tarball releases of the a11y stack. Thanks!
In case of using festival, the problem is same as one described in bug 107638 (speech markers are missing for some speech drivers). For better results you must use ViaVoice. So, this bug is a duplicat of bug 107638. *** This bug has been marked as a duplicate of 107638 ***
I do not think the resolution of this bug (i.e. "must use viavoice or other driver") is satisfactory. We *must* be able to support festival since it is the most commonly available TTS engine.
It is not clear from the thread on this bug whether the problem is a mix of TTS engines with one of them being festival (the known bug #107638), or whether this problem is occuring when the only TTS engine on the system is Festival. Jeff - could you clarify? Also, please note that the general statements: 1. "For better results you must use ViaVoice." and 2. "We *must* be able to support festival since it is the most commonly available TTS engine." are not necessarily at odds. We know that there only certain things we can do if we have speech markers (like making the magnification ROI track the words being spoken by the TTS engine). Also, it is generally accepted that Festival does not speak as clearly or as quickly as other engines (e.g. ViaVoice). "For better results" use something that isn't Festival should be OK. The question is whether we can have a core feature - like this one - not work with Festival and be OK with that. There, I think the answer is as Bill says: this feature should work with Festival. But, must all features? As with the magnification case above, I don't see how we can make that happen short of major modifications to Festival which is outside the scope of the Gnopernicus project.
I only have festival. :-)
I agree with Peter; while we can't expect gnopernicus to provide the same quality user experience/same featureset with Festival as with other TTS engines, the user experience should be reasonably "intact" in both cases. If we are relying so heavily on things like speech callbacks that major features of gnopernicus break when Festival is used, the end result is that gnopernicus+festival is not a useful combination. I think we should continue to target Festival as a usable TTS engine for gnopernicus, thus we need to address problem like this bug. In general we need to make sure that gnopernicus is not _assuming_ that callbacks work, in terms of its output, but rather that gnopernicus is _aware_ of whether callbacks are working, and adjusts its behavior accordingly. The main problem seems to be with sequential/preemptive utterances. I think the desired behavior should be that sequential utterances should not preempt one another unless the client explicitly requests that they do so.
Soory for my bad phrase "For better results you must use ViaVoice." My intention was to say that "with ViaVoice you will achieve the expected results". My english is not so good, so some phrases doesn't show my real intention (what I really want to say) :-). Also I want to say that in my opinion all discutions about support of speach markers for festival and how gnopernicus works with festival (and all speech engines which has no support for speech markers) is the subject of bug 107638. This was the reason why I closed this bug as duplicate of the above one. This bug is only a special case of bug 107638. If that bug will be fixed, then this will be fixed too.
Hi Remus: don't worry about your English, I think I understand what you meant to say. I think you are right, perhaps we should re-close this as a duplicate. However I will mark bug 107638 to mention this discussion. *** This bug has been marked as a duplicate of 107638 ***
Thanks - just reading your comments here is giving me a much better understanding about the challenges and issues involved with a11y support. Great to read! :-)