| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
Restore this commit with a proper bug fix to follow.
|
| |
|
|
|
|
|
|
|
|
| |
This reverts commit bf30024dd7973006bf99d0ae509a7f0022368a41, because
it breaks EMailFormatter/Parser extensions, like the prefer-plain.
The thing is that the internal formatters/parsers (also extensions)
should be always added first, and only after then can be added extended
extensions, which are used before those internal. This constraint was not
satisfied with the reverted commit, the order of extension registration
was unpredictable, depended on GType.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Now we have the following extension points in the GType hierarchy:
E_TYPE_MAIL_FORMATTER_EXTENSION
E_TYPE_MAIL_FORMATTER_PRINT_EXTENSION
E_TYPE_MAIL_FORMATTER_QUOTE_EXTENSION
E_TYPE_MAIL_PARSER_EXTENSION
A registry just needs to be given one of these extension points, and it
can use g_type_children() to find and load all registered extensions.
This eliminates e-mail-format-extensions.[ch] as well as the dynamic
loaders I added a few commits back. Dynamically loaded extensions are
now easier to register, at the cost of internal extensions being a tad
more cumbersome to register. Fair tradeoff, imo.
This also makes e_mail_extension_registry_add_extension() a private
function used only by e_mail_formatter_extension_registry_load() and
e_mail_parser_extension_registry_load().
|
| |
|
|
|
|
|
|
|
| |
With the previous changes, all parser extensions derive from
GObjectClass and implement the EMailParserExtensionInterface.
Simplify things further by making EMailParserExtension an abstract base
class so parser extensions are now just direct subclasses and need not
bother with implementing GObject interfaces.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
EMailExtension is now too trivial to keep as a standalone interface.
Add a 'mime_types' string array to the EMailFormatterExtension and
EMailFormatterParser interface structs.
Alter e_mail_extension_registry_add_extension() to take a 'mime_types'
string array and the GType of an extension to instantiate, rather than
the extension instance directly.
e_mail_extension_registry_remove_extension() is no longer needed.
|
| |
|
|
|
|
|
|
|
|
|
| |
In all implementations for EMailExtension, the MIME type list is a
static string array -- with the single exception of the text-highlight
module, where the MIME type list is dynamically assembled once.
Replace the mime_types() method with a "mime_types" string array in the
EMailExtensionInterface struct. Then the list of MIME types supported
by the class implementing the EMailExtensionInterface can be obtained
without requiring an instance of the class.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Collect EMailParts in a GQueue provided to the EMailParserExtension,
and change the return type of parse() to gboolean to indicate whether
the given CamelMimePart was handled (even if no parts were added to
the output GQueue).
This avoids the awkward corner case of a parser extension returning a
linked list node with a NULL data member to indicate the CamelMimePart
was handled but no EMailParts produced, and then having to watch out
for that NULL data member corner case throughout the application.
Also, remove the GCancellable parameter from e_mail_parser_error() and
e_mail_parser_wrap_as_attachment() since neither function blocks.
|
| | |
|
|
|
This adds 'Format as' submenu to the preview pane context menu.
The submenu is available only for text/plain parts or parts
with a source code (we support about 40 various types). Using
the 'highlight' utility, the formatter processes the part and
highlights the source code it contains.
(discussion in bug #680026)
|
