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.
+ * 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.