Any provider can return a generic error code, which makes the check
useless, only hiding important error information from a user. Since
the camel_getaddrinfo() returns CAMEL_SERVICE_ERROR_URL_INVALID,
the check could be adapted and be more useful.
Connect to the GtkComboBox::changed signal after all candidates are
added, to avoid calling e_source_config_check_complete() before the
candidate has been told to insert widgets. This can cause run-time
warnings such as:
(evolution:7106): evolution-cal-config-webcal-CRITICAL **:
cal_config_webcal_check_complete: assertion `context != NULL' failed
* Use GIO-style async parameters.
* Add mail_folder_cache_note_store_finish().
* Do the bulk of the work in a thread so the logic is more readable.
* Queue multiple calls for the same CamelStore and share the results.
Apparently the migration logic was more complex than it needed to be.
The old numeric key was already synced to the EMailReplyStyle enum in
the source code. Dunno where I got the idea it wasn't.
Just more evidence numeric enum keys are bad.
* Stop using recursive mutexes.
* Give StoreInfo a reference count.
* Give FolderInfo a reference count.
* Track CamelFolders with GWeakRef instead of weak pointers.
* Submit updates directly to the GMainContext, like we do in EDS,
instead of dequeuing them all from a single idle callback that
we then have to track.
Take a CamelStore and folder name instead of a CamelFolder.
CamelStore and folder name can easily be obtained from either a folder
URI or a CamelFolder instance, and the function is more efficient with
separate parameters.
Replaces mail_folder_cache_get_folder_from_uri().
Returns the CamelFolder for the CamelStore and folder name if available,
or else NULL if a CamelFolder instance is not yet cached. This function
does not block.
Returns whether MailFolderCache has information about the folder
described by the CamelStore and folder name. This does not necessarily
mean it has the CamelFolder instance, but it at least has some meta-data
about it.
You can use this function as a folder existence test.
I considered replacing the "session" property with a "registry"
property, but that just complicates application startup even more.
Fact is, if we have a CamelStore then we can get the CamelSession
and even the ESourceRegistry from it. Kinda dirty, but works.
It goes a little something like this...
camel_service = CAMEL_SERVICE (camel_store);
camel_session = camel_service_get_session (camel_service);
mail_session = E_MAIL_SESSION (camel_session);
registry = e_mail_session_get_registry (mail_session);
Removed functions:
mail_folder_cache_get_session()
I've got UI freeze in a call of e_book_client_view_stop() on contact
store dispose, caused by synchronous D-Bus call. Doing the call
in a dedicated thread makes no UI freeze here.
We were using g_object_get() to write an "unsigned int" value (at least
32 bits) into a 16-bit integer address.
Don't know why we were bothering with g_object_get() in the first place,
just call camel_network_settings_get_port() instead.
A resize abort of an event's end time in a day view didn't restore
original event size, because the drawing function updated event's
structure, when it should not. The resize of a start time could be
aborted without any problem.
