GNOME Bugzilla – Bug 347163
Orca ocasionally does not speak or braille new messages
Last modified: 2006-07-17 18:39:48 UTC
Please describe the problem: When a new message arrives or is sent orca ocasionally will not speak or braille it Steps to reproduce: 1. Open a chat in gaim 2. type a message and press enter 3. Wait for a response Actual results: Every once in a while the messages aren't spoken or brailled Expected results: The new messages should always be spoken and brailled Does this happen every time? no Other information: If when this happens you flat review the screen all future messages will be spoken and brailled.
The problem appears to be due to the following test in the gaim.py script: # A new message inserts a carriage return at the end of the # previous line rather than adding to the end of the current # line (I think). So...remove the darn thing. # if text[0] == "\n": Unfortunately this isn't always the case. Certainly not for the first message or after the user has cleared the message area with Conversation->Clear Scrollback. Perhaps a better solution would be have a script variable that kept the previous contents of the message area (initially set to ""), and then when onTextInserted() is called for an event of type ROLE_TEXT, compare the current string value of event.source.text contents with the previous contents and speak/braille the difference, then set the previous contents to the string value of event.source.text. Will, does this seem a reasonable approach?
Ahh, my previous suggestion isn't going to work. There needs to be a saved "previos text" value for the message area for each of the chat rooms the user has currently joined. The chat room name could be the key into a dictionary of these values. The onTextInserted() routine should really look back up the component hierarchy to find the name of the chat room and speak/braille that before it speaks/brailles the new chat message(s). Will, do you want me to hack into this and fix it up now or is this low priority?
Created attachment 68783 [details] New version of the gaim script that hopefully fixes the problem. The script also prepends the chat message(s) with "Message from chat room <chatroomname> ". This allows the user to monitor multiple chat room and know where the messages are coming from. Mike, could you give this script a try and tell me if it works well for you. Thanks.
Created attachment 68785 [details] New version of the gaim script. I also commented out the speaking/brailling of the chat room name (rather than removed it) as maybe it can be reinstated as a hot key at some point.
Changes checked into CVS HEAD. Mike, could you give it a try please? I'm closing it as FIXED. If you are still seeing problems, then please just reopen it. Thanks.
There still is some oddity happening with the new code. I was playing with it last night and was able to reproduce the problem described in the bug. I'm not sure how to reliably cause this to happen, though. Once you tickle gaim via flat review in the manner Mike describes, the problem disappears. In addition, it doesn't always occur when you start gaim. There is some odd logic in the gaim script to muck with focus, and perhaps that is causing this bug to surface under some conditions. As a guess, I wonder if this might be related to receiving two or more messages before you type your next message?
With the recent changes to the gaim script, I think we've fixed this one now. Famous last words. I'm closing it as FIXED. If the problems start happening again, please reopen.