From a cursory glance at the TpAccountManager documentation, I have no idea what signal gets emitted when an account is added. Here are the signals: "account-disabled" : Run Last "account-enabled" : Run Last "account-removed" : Run Last "account-validity-changed" : Run Last "most-available-presence-changed" : Run Last Now I think I remember that, on the D-Bus, AccountValidityChanged is also used to herald the arrival of a new account. So I look at its documentation to check if I'm right: > Emitted when the validity on account changes. > > account is guaranteed to have TP_ACCOUNT_FEATURE_CORE prepared, along with > all features previously passed to tp_simple_client_factory_add_account_features(). > > manager : a TpAccountManager > account : a TpAccount > valid : TRUE if the account is now valid > user_data : user data set when the signal handler was connected. That's not an explanation!
We have account-enabled and its opposite, account-disabled. We have account-removed but no opposite, account-added. I think using account-validity-changed for this on the convenience API is awful, so I'm changing this bug to add an account-added. We could just leave everything else as is as account-validity-changed is in theory still correct (and it's not an API break, etc.)
I changed my mind about this because it might put clients off listening to ::account-validity-changed. Here's just some better documentation. Okay?
+ * The #TpAccountManager::account-removed signal is emitted when + * existing accounts. ... are removed. + * This signal is also used to indicate a new account that did not + * previously exist has been added (with @valid to %TRUE). @valid set to %TRUE. Otherwise looks good; I agree with your rationale.
(In reply to comment #3) > Otherwise looks good; I agree with your rationale. I blame mid-afternoon crushing tiredness. Thanks, pushed.
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.