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.
Keep the EMailUISession define its own implementation of
CamelSession::alert_user(). It's good for couple reasons:
a) dialog is shown above Evolution itself (has parent)
b) info dialogs are shown in an alert bar
e_shell_backend_get_data_dir() already creates the user's data directory
for mail, so there's no need to try and create the directory again.
This eliminates the only usage of the E_SHELL_MIGRATE_ERROR domain.
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.
This fixes three things:
a) mail_display_resource_requested() was leaking file handles on downloaded images
b) it's not necessary to open files, it's enough to test whether file exists
c) mail_display_button_press_event() used incorrect key for "http" cache
If we get a hit from the online database, parse the XML immediately and
store the results in generic internal structs. Then when we're given an
ESource to populate we can feed it the stored results instead of parsing
the XML on demand (and repeatedly).
What this is really doing is making room for other auto-configuration
methods besides the online database lookup.
Use g_resolver_lookup_records() instead of parsing binary DNS records
ourselves (yuck!). Also, realized what we really want are NS records
not MX records. We just want the name server for a given domain.
After providing a name and email address on the Identity page, the user
clicks Forward and auto-configuration runs. If successful, it jumps to
the Account Summary page showing a table of auto-configured settings.
If the user wants to go back and revise auto-configured settings, he
would click Go Back to return to the Identity Page, then click Forward
again to go to Receiving Email (since auto-coniguration only runs once).
But this is confusing. It's not clear that clicking Forward from the
Identity Page will behave differently after auto-configuration has run.
Instead, clicking Go Back from the Summary Page after auto-configuration
should return to the Receiving Email page where IMAP/POP settings can be
modified.
This behavior combined with the GtkAssistant navigation sidebar should
hopefully make it less confusing.
