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 a follow-up for the previous commit, where e_signal_connect_notify*()
functions had been added. Due to a different callback and user data being
attached to the 'notify' signal, the g_signal_handlers_*() functions do not
work properly, thus these e_signal_connect_notify*() functions need
a different way for a signal handler disconnect.
A side-change was done in e-settings-web-view-gtkhtml.c, checking for a real
key change from GSettings.
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.
Users ask from time to time for the old behaviour when the messages
used to be saved through Outbox, rather than the composer being opened
all the time the message is sending. The change is pretty simple,
thus why not to add it.
Note the Outbox is not flushed after sending, the users is responsible
to invoke the Outbox flush on his/her own. This also allows a user
to postpone the message send for later.
Evolution doesn't have any capability to distinguish between truly sent
read receipts and those cancelled, neither it stores anywhere the date
of the read receipt send, thus showing to users an information about
"Sender has been notified..." is only confusing to them.
This ports the following two function calls throughout Evolution:
• e_categories_get_list() to e_categories_dup_list()
• e_categories_get_icon_file_for() to e_categories_dup_icon_file_for()
It necessarily changes some internal e-util API:
• e_util_get_searchable_categories() to
e_util_dup_searchable_categories()
This bumps the EDS requirement to 3.13.1.
https://bugzilla.gnome.org/show_bug.cgi?id=727221
Replaces the 'oklabel' argument when creating a new dialog, and can be
changed after the dialog is created.
This makes EMFolderSelector a little more "subclassable".
Replaces the 'text' argument when creating a new dialog, and can be
changed after the dialog is created.
This makes EMFolderSelector a little more "subclassable".
Replaces the EM_FOLDER_SELECTOR_CAN_CREATE flag, and can also be set
after the selector dialog is instantiated.
This makes EMFolderSelector a little more "subclassable".
The related part of the code could be reached also when the 'syntax' variable
had been previously set to a newly allocated string, thus (try to) free it first.
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.)
The previous code was writing the entire MIME part content to the
highlight utility's stdin pipe before reading the converted result.
With enough content, this caused the write operation to get stuck.
What's worse is this all happens synchronously in the UI thread.
Not sure exactly what was going on, but my hunch proved correct that
we need to simultaneously write to the stdin pipe and read from the
stdout pipe to avoid the deadlock.
Still not happy about this blocking the UI, but that would require
some major refactoring in libevolution-mail-formatter.
The "dialog-apply" icon is not from a set of standard icons, thus
it cannot be used, which I overlooked yesterday. With its drop are
also dropped other button icons in itip-formatter.
The missing icon made EStockRequest "panic" which effectively broke
page rendering for WebKit - the rendering was never finished.
While looking at bug #721286, I found out that mail_shell_view_prepare_for_quit_cb
calls a sync of the folder changes to the server, but mail_backend_prepare_for_quit_cb
does the same thing (or even more, because it calls to synchronize changes in all folders),
thus the former is redundant and can be dropped.
Boy does GSettings like to abort applications! The default value for
the 'junk-default-plugin' key is 'Bogofilter' but if the key's mapping
function cannot find Evolution's Bogofilter integration module (it is
optional after all, so may not be installed), then indicating failure
will make GSettings abort Evolution. So always indicate success.
Drop our explicit gstreamer requirement and merge audio support directly
into libevolution-mail-formatter. We now use the HTML5 <audio> tag and
let WebKit show much nicer playback controls, with volume and seeking.
