This removes all traces of Express Mode from all but the contact editor
and calendar appointment editor. Need to evaluate the remaining cases
individually.
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.
Replaces "paned-view-headers-state", which was defined as an integer for
some stupid reason. Not bothering to migrate the old setting since it's
one button click.
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.
e_config_add_skip_check()
e_config_class_remove_factory()
e_config_create_window()
e_config_page_get()
e_config_page_next()
e_config_page_prev()
e_config_set_page_is_finish()
Also remove E_CONFIG_ASSISTANT and all the assistant support therein.
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.
Exposing data members in the public struct is unwise, especially when
EMailPartList is used from multiple threads. Instead keep the members
private and provide a set of thread-safe functions to manipulate them.
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.
EMailConfigWebView is an extension that configures EWebView instances.
This used to cover both the email formatter and the email composer, but
with the email formatter now using WebKit/GTK+ and the email composer
still using GtkHtml, the composer was left unconfigured.
Add an EMailConfigWebViewGtkHTML extension that targets EWebViewGtkHTML
instances and applies the relevant settings, and remove all the GtkHTML
contortions from EMailConfigWebView.
Word-wrapped GtkLabels and GtkTables just don't seem to get along.
The vertical allocation for the GtkLabel was way too big. Replace
the GtkTable with a GtkGrid.
EMailConfigFormatHTML listens for "changed" signals from a GSettings
instance, passing itself as the 'user_data' to the signal handler. But
the signal handler was left connected after EMailConfigFormatHTML was
finalized, resulting in the signal handler receiving a dangling pointer.
Not using g_signal_connect_object() here because of the unresolved
reference leak issue in GObject. The GSettings instance is likely
cached internally and lives well beyond the EMailConfigFormatHTML.
These functions now return new references:
camel_session_add_service()
camel_session_list_services()
These functions have been renamed and also return new references:
camel_session_get_service() -> camel_session_ref_service()
camel_session_get_service_by_url() -> camel_session_ref_service_by_url()
The evolution-settings capplet was originally designed for Anjal, it was
used in MeeGo as part of the Express Mode effort, but doesn't really fit
in GNOME 3 nowadays (nor did it really fit in GNOME 2, in my opinion).
This is pretty clearly dead weight at this point. The MeeGo developers
have disappeared, and the remaining Evolution developers are not and do
not intend to maintain it. Plus it doesn't even build currently.
This reverses the removal of the "Mark messages as read" preference in
commit e7247d6d60.
I apparently misjudged the popularity of this preference, as there's
been a surprising amout of backlash and confusion as to its removal on
the mailing list, IRC channel, and various distro-support forums.
So, "mea culpa" for removing that one. Haven't heard a peep about the
other removed preferences, however, so they will stay gone.
The story on this is a question [1] was recently posed to the mailing
list about what's the different between "Recent Messages" and "Last 5
Days' Messages" as listed in the Show: combo box, and even I could not
answer before looking up the query expression for "Recent Messages" in
the source code (messages received in the past 24 hours, it turns out).
I can't defend why we need both options, and "Last 5 Days' Messages"
is less ambiguous and overlaps the results for "Recent Messages", so
"Last 5 Days' Messages" seems sufficient to me. There are numerous
ways to re-create the "Recent Messages" query if it's still desired:
saved search, search folder, or just sort messages by date received.
[1] https://mail.gnome.org/archives/evolution-list/2012-July/msg00044.html
