| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
| |
To make Evolution's shared libraries more consistent.
Also add an evolution-mail-formatter documentation module.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Simplify the EABContactFormatter API as follows:
* Drop all constructor arguments from eab_contact_formatter_new()
since get/set functions exist for all of them.
* Remove eab_contact_formatter_format_contact_async() since
EABContactFormatter does not block.
* Replace eab_contact_formatter_format_contact_sync() with
eab_contact_formatter_format_contact() which drops the CamelStream
and GCancellable arguments and takes a GString as an output buffer.
* Remove the "state" and "style" properties, and always use a white
background when rendering the full contact.
This is particularly important since render_normal() dereferenced
the GtkStyle without checking for NULL, which would crash on mails
with a vCard MIME part when "Show Full vCard" was clicked, because
the "vcard-inline" module never set a GtkStyle.
|
| |
|
|
|
| |
EMailPart is reference-counted, subclassed, and allows a custom
finalize function. There's no excuse for it not to use GObject.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Restore this commit with a proper bug fix to follow.
|
| | |
|
| |
|
|
| |
Instead of e_client_utils_open_new() and e_book_client_new().
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
| |
I forgot to include this in 3.7.4, but no matter.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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().
|
| |
|
|
|
|
|
| |
Of the parser extensions that override get_flags(), they all return a
fixed set of flags. So we don't need an instance of the extension to
obtain its flags. Just make it an EMailParserExtensionFlags field in
the class structure.
|
| |
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
Of the formatter extensions that provide a description, they all use a
static string. So we don't need an instance of the extension to obtain
its description. Just make it a string field in the class structure.
|
| |
|
|
|
|
| |
Of the formatter extensions that provide a display name, they all use a
static string. So we don't need an instance of the extension to obtain
its display name. Just make it a string field in the class structure.
|
| |
|
|
|
|
|
|
|
| |
With the previous changes, all formatter extensions derive from
GObjectClass and implement the EMailFormatterExtensionInterface.
Simplify things further by making EMailFormatterExtension an abstract
base class so formatter 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.
|
| |
|
|
|
|
| |
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.
|
| |
|
|
|
| |
Replace the individual components of an EMailPartList with a reference
on the EMailPartList itself in EMailFormatContext. Easier to manage.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Private header, but still need to distribute it.
|
| | |
|
| |
|
|
| |
G_DEFINE_TYPE macros define a static "parent_class" variable.
|
| | |
|
|
|
audio-inline, itip-formatter, prefer-plain, tnef-attachments
and vcard-inline plugins were converted to modules so that they
can fit into concept of the new formatter.
Every module still installs .eplug file, because there is no
suitable API at the moment to register plugins to the plugins dialog
and to extend the Preferences dialog.
|
