| Summary: | CurrentPresence is Offline for online connections not implementing SimplePresence | ||
|---|---|---|---|
| Product: | Telepathy | Reporter: | Andres Salomon <dilinger> |
| Component: | mission-control | Assignee: | Will Thompson <will> |
| Status: | RESOLVED FIXED | QA Contact: | Telepathy bugs list <telepathy-bugs> |
| Severity: | normal | ||
| Priority: | medium | CC: | guillaume.desmottes |
| Version: | 5.6 | Keywords: | patch |
| Hardware: | Other | ||
| OS: | All | ||
| URL: | http://git.collabora.co.uk/?p=user/wjt/telepathy-mission-control-wjt.git;a=shortlog;h=refs/heads/fd.o-24779-CurrentPresence-incorrect | ||
| Whiteboard: | review+ | ||
| i915 platform: | i915 features: | ||
|
Description
Andres Salomon
2009-10-28 15:51:34 UTC
I think the designed behaviour might be that CurrentPresence goes from Offline to Unset? That would make some sense (you don't want to appear as "available" in Empathy if your XMPP account is "busy" and your yafono account is online - you want to appear as "busy"). It's possible that CurrentPresence starts off Unset anyway though. We need a regression test :-( *** Bug 26060 has been marked as a duplicate of this bug. *** If fixing this, please check how telepathy-qt4's Tp::Connection behaves. I think it's something like: * connections of indeterminate status are considered to be UNSET (but Mission Control should rarely have these) * DISCONNECTED and CONNECTING connections are always considered to be (OFFLINE, "offline", "") * CONNECTED accounts are considered to be (AVAILABLE, "available", "") unless they have SimplePresence The easiest fix might be to implement a TP_CONNECTION_FEATURE_SELF_PRESENCE in telepathy-glib, with telepathy-qt4-like semantics, and have MC use it. Related problem: I have two jabber/gabble accounts. When I turn my computer on, neither of them go online. However, both of them are in the onlineAccountsSet in telepathy-qt4. According to wjt, this is beacuse MC sets them to Unset before they have been taken online for the first time that session, which is understood to be an "online" presence. (In reply to comment #3) > * CONNECTED accounts are considered to be (AVAILABLE, "available", "") unless > they have SimplePresence It might be better to consider these to be (UNSET, "", "") or something, since AVAILABLE would break UIs like Empathy's and the N900's that display the most available among the presences: with all other accounts away and a SIP connection with no SimplePresence, the desired display is Away, not Available. This'd be good to have for 5.6.x if it's not too intrusive. Looking into fixing this to obey the spec, which defines that offline accounts should be Offline, and online-but-no-SimplePresence accounts should be Unset. The spec says:
> If the connection is not online, this should be (Connection_Presence_Type_Offline, "", "").
Really? What does it matter what the second string is? As currently implemented, if you connect and then disconnect the account will end up with whatever you fed into RequestedPresence to bring it offline, which is generally going to be (Offline, "offline", ""). We could mandate "offline", since in practice every CM is required to have it; or we could make no assertion, because if you're signing out of IRC maybe you want to have a quit message in your offline RP? :)
oh haiiiiiii (In reply to comment #8) > The spec says: > > > If the connection is not online, this should be (Connection_Presence_Type_Offline, "", ""). > > Really? What does it matter what the second string is? It doesn't, really; mandating "offline", or making no assertion, would both be fine from my point of view (but please change the spec to match). r+ for 5.6 and master. Is anything blocking this? (In reply to comment #10) > It doesn't, really; mandating "offline", or making no assertion, would both be > fine from my point of view (but please change the spec to match). It turns out I made that spec change myself, in 0.21.1, so this is good to go. Merged for 5.6.2 and 5.7.1. |
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.