| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
| |
Use the EMailPartHeaders API instead.
|
| | |
|
| |
|
|
|
| |
EMailPart is reference-counted, subclassed, and allows a custom
finalize function. There's no excuse for it not to use GObject.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Not thread-safe. Use e_mail_formatter_dup_headers() instead.
|
| |
|
|
| |
Duplicates an EMailFormatterHeader struct.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
It could happen that header text color had been picked white one time,
but the other time black as expected (for me usually when I started
Evolution in Calendar and moved to Mail view, the header text color
was white, while when starting in Mail view it was black). The change
to use GtkStyleContext is there only as a cleanup from deprecated
GtkStyle, and to make things easier too, because both GtkStyle
and the GtkStyleContext had set white color for some reason.
|
| |
|
|
|
|
|
|
| |
EShellSettings predates GSettings and is no longer necessary.
GSettings allows binding GObject properties to GSettings keys,
with optional mapping functions. That fulfills the purpose of
EShellSettings.
|
| | |
|
| |
|
|
| |
EPhotoCache already handles this setting.
|
| | |
|
| |
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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().
|
| | |
|
| |
|
|
| |
We define the header flags as an enum type, so use the enum type.
|
| |
|
|
| |
We define the header flags as an enum type, so use the enum type.
|
| |
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
| |
Replace the create_context() and free_context() class methods with a
"context_size" class member defaulting to sizeof(EMailFormatterContext).
EMailFormatter will use "context_size" to allocate a zero-filled slab of
heap memory. Since EMailFormatterQuote is currently the only thing that
overrides the "context_size" (to append a "qf_flags" member), let's keep
this simple.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
This is leftover from the WebKit port and it didn't work
properly. Most of the code was removed, some was moved
to a better place.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
The new formatter was ignoring selected headers, always displaying
only From, To, Subject and Date (default headers).
Handling of the currently displayed headers has been moved to
EMailConfigFormatHTML extension, because it is related to
configuration of EMailFormatter, rather then EMailReader.
|
|
|
All mail-parsing and formatting code has been moved to em-format.
Parsing is handeled by EMailParser class, formatting by EMailFormatter.
Both classes have registry which hold extensions - simple classes
that do actual parsing and formatting. Each supported mime-type
has it's own parser and formatter extension class.
|
