No disrespect to past maintainers, documenters and contributers, but the
Credits section of Evolution's About dialog is a mess and needs a reset.
The list of authors and documenters is YEARS out of date, and it's not
feasible to maintain a complete list of contributors for a project this
large and this old.
Reset the authors list to myself, Milan and Dan and the documenters list
to Andre -- with a nod to past contributers.
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.
I broke contact maps when I removed the settings capplet.
The contact maps feature uses clutter-gtk, so we still need to call
gtk_clutter_init_with_args() instead of gtk_init_with_args() if the
contact maps feature is enabled.
camel_service_get_settings() is now camel_service_ref_settings()
and it returns a new CamelSettings reference which the caller must
release with g_object_unref().
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()
This was another MeeGo feature. MeeGo is dead, the code is starting to
bit rot and crashes on startup, the original author disappeared and the
remaining developers are not interested in maintaining it. So it's out.
Invoke the mbox-to-Maildir conversion directly from main(), just
before the call to e_shell_load_modules().
The reason the code is here and not in the mail module is because
we inform the user at startup of the impending mail conversion by
displaying a popup dialog and waiting for confirmation.
This has to be done before we load modules because some of the
EShellBackends immediately add GMainContext sources that would
otherwise get dispatched during gtk_dialog_run(), and we don't
want then dispatched until after the conversion is complete.
Save the version after the startup wizard has had a chance to
run. If the user chooses to restore data and settings from a
backup, Evolution will restart and the restored data may need
to be migrated.
If we save the version before the restart, then Evolution will
think it has already migrated data and settings to the current
version and the restored data may not be handled properly.
Looks like some ancient development environment script.
I actually use something very similar for my own development
environment, but it doesn't belong in a version control system.
Not the next stable version. If migration needs to occur multiple times
during a development cycle for different reasons, we'll need an accurate
last-used-version stamp.
AFAICT, this key does nothing useful and only confuses me every time I
read the EShell migration code.
The "version" key records the most recently used Evolution version.
That's all we need for migration. And since downgrading Evolution is
not supported, we can assume this value will only increase over time.
