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.
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.
There was called a synchronous version of the ECalClient function
in the main thread, which caused the UI freeze when the backend
(or calendar factory) had been busy with something. This was fine
some time ago, when this function was invoked in a dedicated thread,
but that's not a case for some time. Using async version of the function
avoids the UI freeze.
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
The e_day_view_show_popup_menu() can be called with event_num = -1,
which is when the mouse doesn't hover above any event. The function
tooltip_get_view_event() claims a runtime warning in this case, thus
avoid it by properly testing the passed-in value.
It used focused or unfocused selected color, but the EDayView itself
is not focused at all, it's main_item->parent.canvas instead. Instead
of trying to hunt for this (and updates when the focused widget changes)
just use the same selected color unconditionally, just the way the other
views do it.
I overlooked an issue when replacing GtkStyle with GtkStyleContext
in this part, the all-day events were drawn always black, instead
of with the background color of their calendar.
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.
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.
There were printed two runtime warnings on close of an appointment
editor when the appointment had filled any reminder. It was a side
effect of a recent leak fix in an EAlarmList. The criticals were not
critical, a NULL pointer had been used on a place where it should not.
