From 4f7772afbfe1ce824a37d73e9b260aa83ead25e8 Mon Sep 17 00:00:00 2001 From: Simon McVittie Date: Fri, 6 Sep 2013 11:39:09 +0100 Subject: [PATCH 04/19] TpAccountManager: fix documentation of how many accounts are prepared The documentation had fewer guarantees than the implementation: since 0.16, we've delayed notification of new accounts until they're prepared. --- telepathy-glib/account-manager.c | 13 ++++--------- 1 file changed, 4 insertions(+), 9 deletions(-) diff --git a/telepathy-glib/account-manager.c b/telepathy-glib/account-manager.c index 679000d..502f8da 100644 --- a/telepathy-glib/account-manager.c +++ b/telepathy-glib/account-manager.c @@ -151,15 +151,10 @@ G_DEFINE_TYPE (TpAccountManager, tp_account_manager, TP_TYPE_PROXY) * * When this feature is prepared, the list of accounts have been retrieved and * are available for use, and change-notification has been set up. - * Additionally, the #TpAccount objects for accounts which existed at the time - * this feature was prepared will have #TP_ACCOUNT_FEATURE_CORE prepared, but - * #TpAccount objects subsequently announced by - * #TpAccountManager::account-validity-changed are not - * guaranteed to have this feature prepared. In practice, this means that - * the accounts returned by calling tp_account_manager_dup_valid_accounts() - * immediately after successfully calling tp_proxy_prepare_finish() on the - * #TpAccountManager will have #TP_ACCOUNT_FEATURE_CORE prepared, but later - * calls to that function do not have the same guarantee. + * Additionally, since 0.16 the #TpAccount objects returned by + * tp_account_manager_dup_valid_accounts() have their + * features prepared as configured by the #TpProxy:factory; in particular, + * they will all have %TP_ACCOUNT_FEATURE_CORE. * * One can ask for a feature to be prepared using the * tp_proxy_prepare_async() function, and waiting for it to callback. -- 1.8.4.rc3