aboutsummaryrefslogtreecommitdiffstats
path: root/em-format/e-mail-formatter.c
Commit message (Collapse)AuthorAgeFilesLines
* Bug #699576 - Mail reader frame is black (in the mail view)Milan Crha2013-06-281-2/+7
|
* EMailFormatter: Remove the header API.Matthew Barnes2013-06-081-255/+0
| | | | Use the EMailPartHeaders API instead.
* Define GEnumClass types for mail formatter/parser enums.Matthew Barnes2013-06-051-2/+2
|
* Convert EMailPart to a GObject.Matthew Barnes2013-05-201-1/+1
| | | | | EMailPart is reference-counted, subclassed, and allows a custom finalize function. There's no excuse for it not to use GObject.
* Add e_mail_part_get_mime_type().Matthew Barnes2013-05-201-3/+5
|
* Add e_mail_part_ref_mime_part().Matthew Barnes2013-05-201-5/+8
|
* Add e_mail_part_id_has_suffix().Matthew Barnes2013-05-201-6/+6
|
* Add e_mail_part_get_id().Matthew Barnes2013-05-201-1/+4
|
* em-format cleanups.Matthew Barnes2013-05-201-3/+5
|
* Remove e_mail_formatter_get_headers().Matthew Barnes2013-05-151-16/+0
| | | | Not thread-safe. Use e_mail_formatter_dup_headers() instead.
* Add e_mail_formatter_header_copy().Matthew Barnes2013-05-151-20/+40
| | | | Duplicates an EMailFormatterHeader struct.
* EMailFormatter cleanups.Matthew Barnes2013-05-151-297/+335
|
* Coding style and whitespace cleanup.Matthew Barnes2013-05-081-4/+4
|
* [EMailFormatter] Use GdkRGBA and GtkStyleContext to get theme colorsMilan Crha2013-04-231-50/+56
| | | | | | | | | | 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.
* Remove EMailShellSettings.Matthew Barnes2013-03-171-6/+6
| | | | | | | | 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.
* Bug #690092 - Crash under format_full_headers()Milan Crha2013-03-071-9/+105
|
* EMailFormatter: Remove "only-local-photos" property.Matthew Barnes2013-02-271-48/+0
| | | | EPhotoCache already handles this setting.
* Use CamelMimeFilterToHTMLFlags enum type where appropriate.Matthew Barnes2013-02-071-1/+1
|
* Teach EMailExtensionRegistry to find extensions.Matthew Barnes2013-02-011-2/+3
| | | | Restore this commit with a proper bug fix to follow.
* Revert "Teach EMailExtensionRegistry to find extensions."Milan Crha2013-01-291-3/+2
| | | | | | | | | | 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.
* Consolidate base utility libraries into libeutil.Matthew Barnes2012-12-131-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Teach EMailExtensionRegistry to find extensions.Matthew Barnes2012-12-081-2/+3
| | | | | | | | | | | | | | | | | | | | | 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().
* e_mail_formatter_base_init(): Register internal extension types.Matthew Barnes2012-12-081-3/+29
|
* EMailFormatterContext: Clearify the flags type.Matthew Barnes2012-12-081-3/+3
| | | | We define the header flags as an enum type, so use the enum type.
* EMailFormatterHeader: Clarify the flags type.Matthew Barnes2012-12-081-2/+2
| | | | We define the header flags as an enum type, so use the enum type.
* Make EMailPartList thread-safe.Matthew Barnes2012-12-081-8/+10
| | | | | | 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.
* EMailFormatterContext: Keep a reference to EMailPartList.Matthew Barnes2012-12-081-39/+35
| | | | | Replace the individual components of an EMailPartList with a reference on the EMailPartList itself in EMailFormatContext. Easier to manage.
* EMailFormatter: Simplify context allocation.Matthew Barnes2012-12-081-26/+6
| | | | | | | | | | 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.
* EMailFormatter: Class method rearrangement.Matthew Barnes2012-12-081-156/+156
|
* Address couple issues found by a Coverity scanMilan Crha2012-11-301-2/+6
|
* Coding style and whitespace cleanup.Matthew Barnes2012-11-111-40/+54
|
* Coding style and whitespace cleanup.Matthew Barnes2012-08-201-5/+5
|
* Remove some unused code from EMailReaderDan Vrátil2012-08-091-7/+7
| | | | | | 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.
* Bug #679404 - Read colors for message preview from Gtk themeDan Vrátil2012-07-271-3/+9
|
* Coding style and whitespace cleanup.Matthew Barnes2012-06-251-21/+21
|
* Do not call g_object_notify() when property didn't changeMilan Crha2012-06-181-0/+22
|
* Fix displayed message headersDan Vrátil2012-06-081-0/+20
| | | | | | | | | 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.
* Mail formatter rewriteDan Vrátil2012-06-061-0/+1510
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.