We retrieving the contact list contacts that are offline initially appear as unknown while if they are online and disconnect they appear as offline. This makes sense from a XMPP point of view but less from an application point of view, for instance if I want to display a different icon for offline contacts and contacts that are not in my subscribe list. To test this you can use the list_contacts example in the telepathy-doc.
I've been investigating this, and discovered: * Gabble goes to state Connected before it has retrieved your roster. * If you call GetPresences() after the roster has been retrieved, for a contact who is on your roster but for whom we haven't seen any <presence/> yet, they show up as Offline (that is, Gabble works as this bug requires.) * If you call it before the roster has been retrieved, Gabble says the contact's presence is unknown. This violates the GetPresences() specification, which says it should wait until the roster arrives. So, let's fix GetPresences to wait until the roster arrives, right? Well, no, because: * The same is true of GetContactAttributes(), which is used by TpContact, and which is specified never to wait for network activity. Hence, we have two options: 1. Keep the current behaviour of GetPresences(), and when we get the roster emit PresencesChanged for the entire roster. 2. Wait for the roster to arrive before saying we're online. I think 2. is the way to go; a flood of spurious presence updates for the entire roster seems like a bad idea to me. I'm looking into delaying initial presence until after the roster's been received...
Today I was convinced that emitting PresencesChanged for everyone isn't so bad. <http://lists.freedesktop.org/archives/telepathy/2009-May/003391.html>.
(In reply to comment #2) > Today I was convinced that emitting PresencesChanged for everyone isn't so bad. > <http://lists.freedesktop.org/archives/telepathy/2009-May/003391.html>. > I implemented a slightly different fix: I emit a presence update signal for everyone on the subscribe list when we get the roster.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.