| Summary: | TpAccountManager should have an ::account-added signal | ||
|---|---|---|---|
| Product: | Telepathy | Reporter: | Will Thompson <will> |
| Component: | tp-glib | Assignee: | Jonny Lamb <jonny.lamb> |
| Status: | RESOLVED FIXED | QA Contact: | Telepathy bugs list <telepathy-bugs> |
| Severity: | normal | ||
| Priority: | medium | Keywords: | patch |
| Version: | git master | ||
| Hardware: | Other | ||
| OS: | All | ||
| URL: | http://cgit.freedesktop.org/~jonny/telepathy-glib/commit/?h=new-account-48760 | ||
| Whiteboard: | review+ with minor changes | ||
| i915 platform: | i915 features: | ||
| Bug Depends on: | |||
| Bug Blocks: | 31668 | ||
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.
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!