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.
If sending a message fails but the user was already connected to the
MTA, the error is missed and not handled until further into the logic,
where it's treated as though sending succeeded and only post-processing
failed. This results in the user seeing a copy of the message in Sent,
but the message was never actually sent.
Fallout from the investigation of bug 710807.
