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.
No longer needed. Instead, use g_type_ensure() to ensure the necessary
GalView subclasses are registered in the GType system before loading a
GalViewCollection. Best place to ensure types is from GClassInitFunc.
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
e_table_specification_new() now takes a table specification filename and
a GError and parses the file as part of instance creation. If a file or
parse error occurs, e_table_specification_new() returns NULL.
This replaces e_table_specification_load_from_file().
New functions:
e_table_specification_get_filename()
Removed functions:
e_table_specification_load_from_file()
The returned UID array now has a built-in "free" function for its
elements and should be released by callers with g_ptr_array_unref()
rather than em_utils_uids_free() or some equivalent.
Replaces the "headers" key. Whereas "headers" is an array of XML
blobs, the "show-headers" key is an array of string/boolean pairs.
Also update the appropriate places to get/set the new key.
As discussed recently on the users mailing list [1], there's a strong
precedent among GTK+ applications for F9 to toggle sidebar visibility.
Examples cited were Nautilus, Evince, Totem, Rhythmbox, File-Roller
and gThumb.
Change the Send/Receive accelerator from F9 to F12, and designate F9
as the accelerator for View->Layout->Show Side Bar.
[1] https://mail.gnome.org/archives/evolution-list/2013-May/msg00194.html
It could happen that header text color had been picked white one time,
but the other time black as expected (for me usually when I started
Evolution in Calendar and moved to Mail view, the header text color
was white, while when starting in Mail view it was black). The change
to use GtkStyleContext is there only as a cleanup from deprecated
GtkStyle, and to make things easier too, because both GtkStyle
and the GtkStyleContext had set white color for some reason.
This was added as part of bug 360184 but no justification was given
for the "local-only" part. My Spidey sense tells me it was a hack-
around for the old implementation's tendency to freeze the UI while
searching for a photograph. So the "local-only" option really just
meant "don't freeze the UI for very long, please".
The new EPhotoCache-based implementation in 3.8 NEVER freezes the UI,
so the "local-only" option is no longer needed. If a remote address
book is slow or unresponsive we simply cancel the async photo lookup
when the user moves on to another email.
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.
