Since this change the client is responsible to provide credentials
to use to authenticate backends (through ESource-s, to be more precise),
unless the credentials are already saved.
A simple Evolution run and move between all views means creation of
more than 100 GSettings objects, with only a bit more than 10 schemas.
Reusing the objects should have a positive impact on a performance too.
There are currently only three values: Keep in Outbox, Send immediately
and Send after 5 minutes. It is partly related with the "flush-outbox"
option, but as that is used for filtering, I rather kept it untouched.
The composer/activity showed "Sending message" even when the sent
message had been saving into a configured Sent folder. Changing
the activity description will give a better clue what is happening
in the background.
When there was a send from the Outbox folder, then the transport
service was connected when needed, but not disconnected after
the send was finished. That could mean that any later send from
the Outbox for this service could fail.because the server disconnected
meanwhile.
The previously used g_hash_table_insert() replaces only value for keys
which are already included in the hash table, but as the key is owned
by the value and freed together with the value, then here should
be used g_hash_table_replace(), which replaces both key and value,
thus avoids the use-after-free on the hash table's key.
Similar to GObject::notify, the GSettings::changed can be emitted
even if a key didn't change. It's up to the user (aka evolution)
to test for real changes, thus let's do it. It may have certain
performance positive impact too.
This is related to bug 698275, which did not cover all cases.
The problem here is that the dconf can in certain situation claim
that everything changed (path "/" changed), which GSettingsBinding
propagates to a GObject property unconditionally and GObject's
property setter (g_object_set_property()) also notifies about
the property change unconditionally, despite the real descendant
property setter properly checks for the value change. After all
these false notifications a callback on "notify" signal is called
and possibly an expensive operation is run.
Checking whether the value really changed helps in performance, for
which were added new e-util functions:
e_signal_connect_notify()
e_signal_connect_notify_after()
e_signal_connect_notify_swapped()
e_signal_connect_notify_object()
which have the same prototype as their GLib counterparts, but they allow
only "notify::..." signals and they test whether the value really changed
before they call the registered callback.
Win32 headers have a #define for 'interface', which breaks the build
when this word is used in the code, thus replace it to 'iface',
the same way as GLib or GTK+ code use to have it. (See bug #722068.)
CamelFolder holds a weak reference to its parent CamelStore, thus
if the store is freed before the folder, then the folder cannot
access it, which can lead to crashes.
Turns out this function was a no-op, because nothing registered itself
to be cancelled this way. This was part of the legacy async framework,
which we've mostly moved away from now.
This makes the code free of Coverity scan issues.
It is sometimes quite pedantic and expects/suggests some
coding habits, thus certain changes may look weird, but for a good
thing, I hope. The code is also tagged with Coverity scan
suppressions, to keep the code as is and hide the warning too.
Also note that Coverity treats g_return_if_fail(), g_assert() and
similar macros as unreliable, and it's true these can be disabled
during the compile time, thus it brings in other set of 'weird'
changes.
