Created attachment 117749 [details] Implement unset connection presence type in Tp::PresenceSpec. We use this in a few places, and have to manually create the presence. This patch makes it simpler to create such presences.
*Bump*
What is the context of use of this? The spec says "unset" is an invalid presence, used as the null value. This would be equivalent to creating a PresenceSpec() using the default constructor in tp-qt. Why do you specifically need to use "unset"?
Unset presences can indicate that an account-specific override presence is required because there is no specific presence tied to that account set by a user. It can also indicate that there is no auto presence available, and that the user presence (or override) should be used. Loading a set of user presences from disk should also use an unset presence type for unfound entries. Ideally, it would make sense to have all new presences created use this spec definition. Is there really any reason to return a Tp::ConnectionPresenceType of Unknown instead? Unknown seems to be only for unsubscribed contacts, not user set presences.
(In reply to James Smith from comment #3) > Ideally, it would make sense to have all new presences created use > this spec definition. Is there really any reason to return a > Tp::ConnectionPresenceType of Unknown instead? Unknown seems to be only for > unsubscribed contacts, not user set presences. You are right about that. A an invalid PresenceSpec, created with the default constructor, should return Unset instead of Unknown as its type. I will change that in 1.0. Then we will only need a Presence::unknown() method and this will cover it all. I think this is better than having a Presnce::unset() method, as it kind of contradicts the spec (Unset vs Unknown).
The original patch should also be included, since it can also be useful to clear an existing presence.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/telepathy/telepathy-qt/issues/49.
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.