In the event of an address book backend abort, EClientCache detects this
and invalidates its cached EClient (if it has one), so a new instance is
created on the next request.
EAddressbookModel is only handed an EClient once, which may become stale
if the backend aborts. And even if the backend is restarted the address
book will remain unresponsive in Evolution.
This commit changes the behavior so that every time an address book is
selected in the side bar, a fresh EClient instance is obtained from the
EClientCache and handed to the EAddressbookModel. If the model already
has that EClient instance, nothing happens. Otherwise the model resets
itself and creates a new EBookClientView.
This accidentally got dropped during the "account-mgmt" project.
As much as I loathe EConfig, the "Automatic Contacts" plugin is useless
without its Preferences page in the Contacts section.
The default value for these GSettings keys is an empty string. The
mapping function should handle empty strings by falling back to the
appropriate default ESource.
EShellSettings predates GSettings and is no longer necessary.
GSettings allows binding GObject properties to GSettings keys,
with optional mapping functions. That fulfills the purpose of
EShellSettings.
Collect all the "config" extensions from the "addressbook", "calendar",
and "mail" modules into one place. These extensions typically just bind
GObject properties of extensible classes to app-specific GSettings keys.
Move the supporting widgets for the contact maps feature alongside
EABContactDisplay. Removing them from libeutil helps isolate our usage
of libchamplain so it's not imposed on the entire application, and even
3rd party software. That libchamplain is an optional dependency only
further complicates the matter.
Ideally I'd like to somehow isolate this feature in an extension module,
but we currently lack sufficient hooks for such an extension. So this
arrangement will have to suffice for now.
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.
For consistency with the Preferences window. We assume the display
names are server-assigned and not user-assigned, at least not assigned
through Evolution.
EBookSourceConfig drags in no additional dependencies, and allows us to
delay publishing a libevolution-addressbook.so since 3rd party packages
will need to subclass EBookSourceConfig.
The address book source code will need to be flattened into a single
library before we could publish a libevolution-addressbook.so anyway.
That would be a good thing to do regardless -- Evolution has way too
many internal libraries -- but it's out of scope at the moment.
Drop the "libevolution" prefix so it's not so verbose and also
consistent with upcoming evolution-data-server module libraries.
libevolution-module-foo.so --> module-foo.so
