There still left some references to GtkHTML in the "active code",
which should be dropped. There still can be found couple "GtkHTML"
strings in the code, but mostly in disabled code or comments only.
These are to be fixed separately.
It turned out that the values returned from ml_tree_value_at_ex() can
be dynamically allocated, thus proper free functions should be called
for these too.
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.
It was quite discouraging to change order of mail accounts when it
reset to default sort order when a new account had been added or
an old removed. Rather than reset the order, the Evolution should
adapt the account count change properly, same as sort newly added
accounts by the default sort function.
In some cases, like on errors or cancel, there could be left
an information in the message-list that the list is generating
its content, while it didn't do it in reality. This always resets
the message-list information in case the current message-list
generation finished and was the last in the queue.
Otherwise invalid source ID is used in the call of g_source_remove()
when is tried to remove "pending" auto-mark-as-seen timeout callback.
It can show a runtime warning on a console too.
This used to be done in mail_cancel_all(), but since commit 8ae3cc3283
the function is gone and the mail operations are not cancelled, which
prevents the application to go offline or to quit in a timely manner,
because it's waiting for a finish of possibly expensive operations.
Convert the folder selector's "New" button to a [+] button on an inline
toolbar beneath the folder tree. The symbolic button looks better, and
clicking it no longer triggers a "response" signal, which terminates a
gtk_dialog_run() call. We don't want gtk_dialog_run() to terminate in
this case.
Now that all the instantiation arguments have either been eliminated or
made into GObject properties, we can initialize the dialog properly via
the constructed() method instead of some custom internal function.
This makes EMFolderSelector a LOT more "subclassable".
Milan Crha