GNOME Bugzilla – Bug 657703
Issues with userMenu's session management
Last modified: 2011-09-08 22:36:44 UTC
Empathy master does no longer do any session management when using the Shell (bug #656631). While testing this feature (locking/unlocking the screen) I noticed some issues in the way Shell's is handling presence. a) The status passed to tp_account_manager_set_all_requested_presences() is wrong (bug #657696). b) When locking the screen, the session state goes to idle which is fine. The Shell changes the status of all IM accounts to XA. But during the process _IMStatusChanged() is called with 'available' as a presence (not sure why, maybe because the accounts don't all go away immediatelly) so the Shell sets the session state back to available --> IM accounts are not XA as expected. c) If I remove the call in _IMStatusChanged setting the session status to available, the accounts are XA as expected. But when I unlock the screen they stay XA instead of going back as available.
Created attachment 195476 [details] [review] user-menu: Keep track of current presence We keep track of presence changes by connecting to the Tp.AccountManager:most-available-presence-changed signal. However, if multiple accounts are in use, telepathy may lie to us and emit the signal even when the most available presence is unchanged. Work around this by keeping track of the current presence ourselves. (In reply to comment #0) > Empathy master does no longer do any session management when using the Shell > (bug #656631). Yay! > b) When locking the screen, the session state goes to idle which is fine. The > Shell changes the status of all IM accounts to XA. But during the process > _IMStatusChanged() is called with 'available' as a presence (not sure why, > maybe because the accounts don't all go away immediatelly) so the Shell sets > the session state back to available --> IM accounts are not XA as expected. Yeah, I can only reproduce the issue with multiple accounts. Quick testing suggests that the attached patch fixes the issue, though if that is indeed the case, the issue is arguably a telepathy issue (for emitting a 'changed' signal when there was no actual change; if that behavior is expected, at least the signal's documentation should be updated to mention it :-)
You're right, something is weird with this signal. I'll do some digging.
Actually this signal could be fired if only, say, the message changed, so you still need to check if the presence actually changed; so your patch is good.
Attachment 195476 [details] pushed as 8adc193 - user-menu: Keep track of current presence
*** Bug 658165 has been marked as a duplicate of this bug. ***