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.
This makes the code free of Coverity scan issues.
It is sometimes quite pedantic and expects/suggests some
coding habits, thus certain changes may look weird, but for a good
thing, I hope. The code is also tagged with Coverity scan
suppressions, to keep the code as is and hide the warning too.
Also note that Coverity treats g_return_if_fail(), g_assert() and
similar macros as unreliable, and it's true these can be disabled
during the compile time, thus it brings in other set of 'weird'
changes.
gal_view_collection_new() now takes system and user directory arguments
and loads GalViews during instance initialization.
Removed functions:
gal_view_collection_set_storage_directories()
gal_view_collection_load()
gal_view_collection_loaded()
EShellView no longer needs help from subclasses other than getting
the needed GalView subclasses registered.
A nice side-effect of this is EShellView subclasses can now use the
G_DEFINE_DYNAMIC_TYPE macro.
EShellView now holds a reference to the active GalViewInstance. Where
applicable, the EShellView subclass is responsible for keeping this up
to date when the sidebar selection changes.
Holding a reference allows EShellView to implement common actions like
"Save Current View" directly instead pushing it on to subclasses.
New functions:
e_shell_view_get_view_instance
e_shell_view_set_view_instance
This removes all traces of Express Mode from all but the contact editor
and calendar appointment editor. Need to evaluate the remaining cases
individually.
Evolution consists of entirely too many small utility libraries, which
increases linking and loading time, places a burden on higher layers of
the application (e.g. modules) which has to remember to link to all the
small in-tree utility libraries, and makes it difficult to generate API
documentation for these utility libraries in one Gtk-Doc module.
Merge the following utility libraries under the umbrella of libeutil,
and enforce a single-include policy on libeutil so we can reorganize
the files as desired without disrupting its pseudo-public API.
libemail-utils/libemail-utils.la
libevolution-utils/libevolution-utils.la
filter/libfilter.la
widgets/e-timezone-dialog/libetimezonedialog.la
widgets/menus/libmenus.la
widgets/misc/libemiscwidgets.la
widgets/table/libetable.la
widgets/text/libetext.la
This also merges libedataserverui from the Evolution-Data-Server module,
since Evolution is its only consumer nowadays, and I'd like to make some
improvements to those APIs without concern for backward-compatibility.
And finally, start a Gtk-Doc module for libeutil. It's going to be a
project just getting all the symbols _listed_ much less _documented_.
But the skeletal structure is in place and I'm off to a good start.
Prefer dealing with GdkEvent pointers and using accessor functions like
gdk_event_get_button().
This is complicated by the fact that some GtkWidget method declarations
still use GdkEventButton pointers, and synthesizing button events pretty
much requires direct GdkEventButton access. But GDK seems to be nudging
itself toward sealing the GdkEvent union. Likely to happen in GDK4.
Mainly clean up signal handlers and leave method overrides alone for now.
The EModule, EExtensible and EExtension classes as well as the
e_type_traverse() function have been moved to Evolution-Data-Server's
libebackend library to replace e-data-server-module.c.
Now Evolution-Data-Server modules use the same framework as Evolution.
With unintrusive error dialogs gone, we can cut some unnecessary bits
out of EActivity.
I'm also adding a new enum property called "state", which is one of:
E_ACTIVITY_RUNNING
E_ACTIVITY_WAITING
E_ACTIVITY_CANCELLED
E_ACTIVITY_COMPLETED
The state of an activity must be explicitly changed. In particular,
when the user cancels an activity the state should be set only after
confirming the operation has been cancelled and not when cancellation
is requested (e.g. after receiving a G_IO_ERROR_CANCELLED, not when
the GCancellable emits "cancelled"). EActivityBar and EActivityProxy
widgets have been updated to make this distinction clearer in the UI.
E_ACTIVITY_WAITING will be used when activities have to be queued and
dispatched in sequence, which I haven't written yet.
