em_folder_tree_get_selected_folder() currently blocks, and I'm about to
remove the function. But there's a couple places where we just need to
block for now, else it would require a significant rewrite. So execute
the em_folder_tree_get_selected_folder() logic manually in those places.
This will force Evolution to reconnect to the service using the current
settings. However this is not a complete solution. If the new settings
now point to a completely different mail account, we leave behind cached
messages and database tables from the previous account such that you end
up with some weird hybrid of the previous account and current account.
I guess for now the answer is "don't do that", but we should try to
handle that more gracefully in the future -- more for architectural
correctness than it being a common real world use case.
Emitted after all changes are successfully committed over D-Bus.
Can connect to this signal to perform followup actions, such as
disconnecting the corresponding CamelService.
This function removed a CamelStore from EMFolderTreeModel and then added
it again in response to the corresponding ESource emitting a "changed"
signal (presumably from editing a mail account and saving changes).
In the past this was the only way for changes to the account URI string
to take effect without restarting Evolution. But we have CamelSettings
now and don't need this hack anymore. Time for it to die.
Openning the Preferences dialog for the first time causes many
property bindings to be created. GLib emits a lot of ::notify signals
during this, one of them being about image-loading-policy.
We now correctly check, whether the change was to allow loading
images, or not (and we don't display them in that case).
Finaly, e_mail_display_reload() will always schedule the action via
g_idle_add() so that we can merge plenty of _reload() calls caused by
the afformentioned ::notify emitions into single call when all the noise
is over.
Remove mail_folder_cache_service_added() and rely instead on
mail_folder_cache_service_enabled()/disabled(). Despite the function
names the folder cache doesn't actually care about enabled status, it
simply maintains a set of CamelStores to monitor. We should refactor
the folder cache API to better reflect that.
EMailAccountStore always immediately follows a "service-added" signal
emission with either a "service-enabled" or "service-disabled" emission,
which will add or remove the service from the folder cache.
