[Bug 34572] Weird signal order and duplicate signals for Account properties

[bugzilla-daemon at freedesktop.org]

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.