The application/postscript mime type had been handled by the text-hightlight
module, but thinking of it, it doesn't make much sense, because most users
would prefer to see the content rather in a postscript viewer, than
the source of the postscript file, thus this change removes the mime type
from the text-hightlight module. There had been also issues about thinking
that certain parts had been handled, while they did not, which this change
fixes as well.
The issue had been reported downstream at:
https://bugzilla.redhat.com/show_bug.cgi?id=1187327
There could happen a busy loop on a Month view select, when the week
starts on Sunday was set. The date range clamp made the first day Sunday,
but the Month view itself corrected it to Saturday (it doesn't split
weekends), this was noticed and the time range was recalculated
again, by six days back. Then the round repeated down to 1970, till
a runtime critical warning wasn't hit.
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.
There is a fake change notify on timezone when either a corresponding
file changes or the setting for "use system timezone" changes,
to propagate the change in the code properly. This notify requires
proper key identification for GSettings bindings, because without it
the binding crashes on a runtime check.
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.
This is related to an ESourceSelector, which checks ESource's
selected state when it is removed or disabled, but the corresponding
row in the selector could be already gone, which could produce
a runtime warning about invalid GtkTreeRowReference.
This was a remaining thing from the 'Make calendar views non-UI-blocking'
work, to show progress of views in UI. This is currently done by a spinner
beside source's name in the ESourceSelector and a tooltip above that row.
The translation should be merged into the appdata related files.
The evolution.appdata.xml.in had been moved due to
INTLTOOL_XML_NOMERGE_RULE being used for gsettings schemas.
These are useful for GNOME Software, to show the plugins as an addon
for the Evolution. Packagers can decide what to do with the file,
either they can add it into the respective subpackage or they can
just ignore (remove) the files, if they do not build special packages
for these plugins.
The Calendar, Memos and Tasks views use to do D-Bus calls to
the backends on the main (UI) thread, which could result in UI
freezes, until the operation was done on the backend (and server)
side. This commit fixes that by invoking the operations in
a dedicated thread. It has few additional advantages too:
- operations can be cancelled
- proper error reporting to a user
- less code duplication between the views for common operations
There had been fixed some performance issues when selecting/unselecting
sources in the source selector as well.
* use e_util_win32_initialize() in main() to avoid code duplication
* e-spinner - correct image path build under win32
* export WIN32_SERVICELIBEXECDIR when building eds, which relies on it now
* update D-Bus patch and session-local.conf creation, thus D-Bus
can actually autostart services
Namely "Use the same fonts as other applications", "Standard Font",
"Fixed Width Font", "Highlight quotations with color", "Automatically
insert emoticon images" and "Check spelling while I type". Also remove
unneded properties from EWebView.
The icons at the search bar, to search forward, backward and stop
searching were too large, which didn't look good. This makes them
smaller, though even here can be seen a little gap around
the images in the buttons which might not be there ideally.
Using "Server requires authentication" checkbox doesn't update
the new mail account dialog properly, thus it seems like a username
is required when the server does not require authentication. It's due
to the dialog being updated properly only on CamelSettings changes,
while this checkbox doesn't have any direct connection to any
CamelSettings property.
This makes evolution depend on theme-defined named colors, namely:
theme_bg_color
theme_base_color
theme_fg_color
theme_text_color
theme_selected_bg_color
theme_selected_fg_color
theme_unfocused_selected_bg_color
theme_unfocused_selected_fg_color
If it's not defined, then a fallback color is used, in the worse case
one of the fallbacks defined in evolution itself.
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.
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.
