With libpurple, it is not possible to know the available statuses until you connect. But telepathy-haze has to supply an array of TpPresenceStatusSpecs to tp_presence_mixin_class_init. Perhaps tp_presence_mixin_class_init could accept a NULL statuses, in which case objects using the mixin would have to call a hypothetical presence_mixin_set_statuses to set the possible statuses for this connection.
This is also needed in gabble since it supports custom presence statuses to be set by plugins. ATM in gabble we're also doing it at mixing class init time, which is not very nice.
I want to simplify the presence mixin's API anyway, so I might do this now.
(In reply to comment #0) > With libpurple, it is not possible to know the available statuses until you > connect. This is OK for the Connection, but makes Protocol.Interface.Presence unimplementable - we can't even guess what statuses a given protocol will support until we connect to it :-( So solving this for the TpPresenceMixin would be nice, but still insufficient for a nice UI. I wonder whether we'd be better off with some sort of "cache the last known available-presence-statuses per account in MC" arrangement...
-- 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-glib/issues/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.