It could happen that a message was sent from Outbox before the set
timeout. This change makes sure that messages which are not in
the Outbox folder for long enough are not sent earlier. Users still
can flush the Outbox earlier from the context menu or from
File->Send/Receive->Send All (the "Send/Receive" action doesn't
skip this timeout).
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.
