GNOME Bugzilla – Bug 348693
Evolution announcement of new mail should be togglable
Last modified: 2008-07-22 19:24:23 UTC
The ability to announce new email messages in Evolution, should be settable based on whether Evolution currently has focus or not. There may be instances where a user is running another application, whjere they do not want to know whether there are new incoming email messages.
I have observed, that when arrives new mail, Orca looses focus even if you are reading an e-mail message. If focus is on the body of the message and arrives a new one while you are reading, Orca announces changes into the list of messages component and you have to give focus again to the body in order to continue reading. I don't know if this is related to this or perhaps it should be turned into a bug instead of a RFE.
After talking with Will on this, the approach we are going to take is as follows. * There will be a new variable in script.py called presentIfInactive (default value of False). * In _processObjectEvent() in focus_tracking_presenter.py a check will be made to see if the event is for an application that's not the current active one. If it is, and presentIfInactive is False, then that event is not processed. * Scripts (such as gaim) can set self.presentIfInactive to True, in order to get feedback on things like new chat massages being read.
The other part that I forgot to add yesterday was: * add in an Insert-m hot-key handler to the Evolution script so that it will toggle the self.presentIfInactive setting and therefore toggle the presenting of new email.
Add accessibility keyword. Apologies for spam.
Created attachment 74836 [details] [review] Patch to hopefully fix the problem. This also fixes bug #257169.
Changes checked in CVS HEAD. Closing as FIXED. Javier, if you are still seeing the problem in comment #1, please file a separate bug. If this is indeed happening, then it's a bug in Evolution, and I'll file a bug there, and block the new Orca bug against it. Thanks.
*** Bug 357169 has been marked as a duplicate of this bug. ***
Note that we decided to reverse the default action of presentIfInactive. See the second patch to bug #363423.