[Bug 34572] Weird signal order and duplicate signals for Account properties
bugzilla-daemon at freedesktop.org
bugzilla-daemon at freedesktop.org
Thu May 19 17:52:09 CEST 2011
https://bugs.freedesktop.org/show_bug.cgi?id=34572
--- Comment #1 from Simon McVittie <simon.mcvittie at collabora.co.uk> 2011-05-19 08:52:07 PDT ---
(In reply to comment #0)
> Repeat of Connection Object Path: "/"
There's a set of connection-related properties (connection path, status,
status-change reason) which always change together: if one of them changes, all
of them are signalled. The idea was to make the signals more comprehensible in
dbus-monitor or whatever.
> HasBeenOnline changed to true, but it already gave a valid connection object
> path... and it repeat again the connection object path.
HasBeenOnline should probably be emitted in the same freeze/thaw set as the
bundle of connection-related properties, yes.
> presence changed to available after connection is known... that should happen
> at the same time, no?
We don't necessarily know the presence yet, iirc. (For implementations that
happen to emit PresenceChanged while connecting, like Gabble, I agree we might
be able to do better.)
> Since the account already has a connection, those should be already known and
> could be signaled together with the connection, no?
>
> tp-qt4 0.5.6 DEBUG: Account::updateProperties: changed:
> tp-qt4 0.5.6 DEBUG: Nickname: "debirox at gmail.com"
> tp-qt4 0.5.6 DEBUG: Normalized Name: "debirox at gmail.com"
Nickname is retrieved asynchronously, using Aliasing; it isn't immediately
known.
Normalized name is currently retrieved asynchronously by calling InspectHandles
on the self-handle, although now that we have tp_connection_get_self_contact()
we could avoid that.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.
More information about the telepathy-bugs
mailing list