Attempts to derive a suggested filename from the given URI for use in a
"Save As" dialog.
By default the suggested filename is the last path segment of the given
URI (the unless the given URI looks like a query), but subclasses can use
other mechanisms for custom URI schemes. For example, "cid:" URIs in an
email message may refer to a MIME part with a suggested filename in its
Content-Disposition header.
Replaces the given URI with a redirected URI as necessary, primarily for
use with custom SoupRequest handlers. Typically this function would be
called just prior to handing a request off to a SoupSession, such as
from a WebKitWebView "resource-request-starting" signal handler.
Case in point: EMailDisplay now implements the redirect_uri() method,
and calls it from its own "resource-request-starting" signal handler.
Don't expose public API for this.
Even though it's still possible through the WebKitWebView API, we don't
want to encourage setting an arbitrary WebKitWebSettings on an EWebView.
Removed functions:
e_web_view_set_settings()
e_web_view_get_default_settings()
nautilus-sendto has been stripped of its usefulness in GNOME 3.8.
It no longer has a UI of its own, it just immediately spawns a mail
client with a set of files as attachment arguments for a new message.
There's no reason for Evolution to be invoking it anymore.
Evolution is still occasionally getting stuck on shutdown, and although
the evolution-shell log domain shows debug messages for activities that
are preventing shutdown, they frequently look like this:
(evolution:13534): evolution-shell-DEBUG: 5 active 'mail' activities:
(evolution:13534): evolution-shell-DEBUG: * (no description)
(evolution:13534): evolution-shell-DEBUG: * (no description)
(evolution:13534): evolution-shell-DEBUG: * (no description)
(evolution:13534): evolution-shell-DEBUG: * (no description)
(evolution:13534): evolution-shell-DEBUG: * (no description)
I think the lack of descriptions is from CamelOperations popping all
their pushed messages, which is correct behavior but doesn't help us
debug the problem.
e_activity_get_last_known_text() returns the most recent _non-empty_
text value set on the EActivity. So our debug message can fall back
to that if the EActivity has no description at shutdown:
(evolution:13534): evolution-shell-DEBUG: * (was "blah, blah, blah")
gal_view_collection_new() now takes system and user directory arguments
and loads GalViews during instance initialization.
Removed functions:
gal_view_collection_set_storage_directories()
gal_view_collection_load()
gal_view_collection_loaded()
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.
Just readable for now, but I plan to make it also construct-only.
(Despite the precendence, I prefer "user" over "local" for the name.)
New functions:
gal_view_collection_get_user_directory()
All GalView subclasses return a static string in their get_type_code()
methods, so replace the method with a static string pointer directly in
the class structure, and remove the "type-code" GalView property.
Instead, lazily load the state file once an ETable or ETree is attached,
since we need its ETableSpecification to create an ETableState instance.
This means GalViewFactoryEtable can lose its ETableSpecification too.
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()
No longer used outside of e-table-specification.c.
Its logic is merged into e_table_specification_load_from_file(), but
that too will be removed momentarily.
