[Bug 31195] Implement models

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Tue Jan 11 19:26:30 CET 2011


https://bugs.freedesktop.org/show_bug.cgi?id=31195

--- Comment #11 from Olli Salli <ollisal at gmail.com> 2011-01-11 10:26:29 PST ---
Additional bits about the implementation (Telepathy usage only. I trust you in
getting the actual qt model implementation stuff right better than I ever would
notice with my limited knowledge):

  50 void AccountsModelItem::Private::setStatus(const QString &value)
  51 {
  52     Presence presence = mAccount->currentPresence().barePresence();
  53     presence.setStatus(Tp::ConnectionPresenceTypeUnset, value, QString());
  54     mAccount->setRequestedPresence(presence);
  55 }
  56 
  57 void AccountsModelItem::Private::setStatusMessage(const QString &value)
  58 {
  59     Presence presence = mAccount->currentPresence().barePresence();
  60     presence.setStatus(Tp::ConnectionPresenceTypeUnset, QString(), value);
  61     mAccount->setRequestedPresence(presence);
  62 }
  63 

>From the Telepathy D-Bus interface specification for Account.RequestedPresence
(which setRequestedPresence manipulates): "The Connection_Presence_Type in this
property MUST NOT be Unset, Unknown or Error.". So, you're working against the
spec here.

The spec also doesn't guarantee, or even hint that an unset/invalid value in
one of the fields would mean keeping the current value. If you see such
behavior currently, that's just an implementation artifact of MC (or whatever
you're using there).

Additionally, as Andre pointed out, setting both the status and the message at
the same time would be more sensible, and not only for performance reasons: on
many protocols, only a subset of all the available statuses support a message.
So, one would need for the AM and CM to process the status change request, and
make a round-trip to the IM server to set the presence, and the stack to pick
up the change before you could actually set the message. (Also, the fact that
setStatus currently secretly clears the message seems error-prone).

Unfortunately, correctly setting presence for all accounts would require
implementing
http://telepathy.freedesktop.org/spec/Protocol_Interface_Presence.html (in CMs,
some data files, and tp-qt4). That's definitely a TODO item for us: we'll
implement a Tp::Account::allowedPresenceStatuses() which uses info from a
connected connection if any, the service-specific profile file and that D-Bus
interface (and the corresponding serialized information in data files). Andre
says this is possible to accomplish sometime next week.

Why are implementation helper functions like AccountsModelItem::clearContacts
and addKnownContacts public?

What's the rationale for (dis)connectChannelQueue()?

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.



More information about the telepathy-bugs mailing list