Bug 34572 - Weird signal order and duplicate signals for Account properties
Summary: Weird signal order and duplicate signals for Account properties
Status: RESOLVED MOVED
Alias: None
Product: Telepathy
Classification: Unclassified
Component: mission-control (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Telepathy bugs list
QA Contact: Telepathy bugs list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-02-22 07:15 UTC by Xavier Claessens
Modified: 2019-12-03 19:35 UTC (History)
0 users

See Also:
i915 platform:
i915 features:

Attachments

Description Xavier Claessens 2011-02-22 07:15:16 UTC 
Here is the signals how tp-qt4 gets them:

tp-qt4 0.5.6 DEBUG: New account "/org/freedesktop/Telepathy/Account/gabble/jabber/debirox_40gmail_2ecom0" 

tp-qt4 0.5.6 DEBUG: Account::updateProperties: changed: 
tp-qt4 0.5.6 DEBUG:  Valid: true 
tp-qt4 0.5.6 DEBUG: Account::updateProperties: changed: 
tp-qt4 0.5.6 DEBUG:  Interfaces: ("org.freedesktop.Telepathy.Account", "org.freedesktop.Telepathy.Account.Interface.Avatar", "com.nokia.Account.Interface.ChannelRequests", 
tp-qt4 0.5.6 DEBUG:  Service Name: "google-talk" 
tp-qt4 0.5.6 DEBUG:  Enabled: true 
tp-qt4 0.5.6 DEBUG:  Parameters: QMap(("account", QVariant(QString, "debirox@gmail.com") ) ( "fallback-conference-server" ,  QVariant(QString, "conference.jabber.org") ) ( 
tp-qt4 0.5.6 DEBUG:  Automatic Presence: 2 - "available" 
tp-qt4 0.5.6 DEBUG:  Current Presence: 1 - "" 
tp-qt4 0.5.6 DEBUG:  Requested Presence: 1 - "offline" 
tp-qt4 0.5.6 DEBUG:  Connection Object Path: "/" 
tp-qt4 0.5.6 DEBUG:  Connection StatusReason: 1 

Repeat of Connection Object Path: "/"

tp-qt4 0.5.6 DEBUG: Account::updateProperties: changed: 
tp-qt4 0.5.6 DEBUG:  Changing Presence: true 
tp-qt4 0.5.6 DEBUG:  Connection Object Path: "/" 
tp-qt4 0.5.6 DEBUG:  Connection Status: 1 

tp-qt4 0.5.6 DEBUG: Account::updateProperties: changed: 
tp-qt4 0.5.6 DEBUG:  Requested Presence: 2 - "available" 

tp-qt4 0.5.6 DEBUG: Account::updateProperties: changed: 
tp-qt4 0.5.6 DEBUG:  Connects Automatically: true 

tp-qt4 0.5.6 DEBUG: Account::updateProperties: changed: 
tp-qt4 0.5.6 DEBUG:  Connection Object Path: "/org/freedesktop/Telepathy/Connection/gabble/jabber/debirox_40gmail_2ecom_2f601a27bb" 

Repeat of object path

tp-qt4 0.5.6 DEBUG: Account::updateProperties: changed: 
tp-qt4 0.5.6 DEBUG:  Connection Object Path: "/org/freedesktop/Telepathy/Connection/gabble/jabber/debirox_40gmail_2ecom_2f601a27bb" 

HasBeenOnline changed to true, but it already gave a valid connection object path... and it repeat again the connection object path.

tp-qt4 0.5.6 DEBUG: Account::updateProperties: changed: 
tp-qt4 0.5.6 DEBUG:  HasBeenOnline changed to true 
tp-qt4 0.5.6 DEBUG:  Connection Object Path: "/org/freedesktop/Telepathy/Connection/gabble/jabber/debirox_40gmail_2ecom_2f601a27bb" 
tp-qt4 0.5.6 DEBUG:  Connection Status: 0 

presence changed to available after connection is known... that should happen at the same time, no?

tp-qt4 0.5.6 DEBUG: Account::updateProperties: changed: 
tp-qt4 0.5.6 DEBUG:  Current Presence: 2 - "available" 
tp-qt4 0.5.6 DEBUG:  Changing Presence: false 

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@gmail.com" 
tp-qt4 0.5.6 DEBUG:  Normalized Name: "debirox@gmail.com"
Comment 1 Simon McVittie 2011-05-19 08:52:07 UTC 
(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@gmail.com" 
> tp-qt4 0.5.6 DEBUG:  Normalized Name: "debirox@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.
Comment 2 GitLab Migration User 2019-12-03 19:35:07 UTC 
-- 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-mission-control/issues/37.

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.