aboutsummaryrefslogtreecommitdiffstats
path: root/em-format/e-mail-formatter-print.c
Commit message (Collapse)AuthorAgeFilesLines
* Coding style and whitespace cleanup.Matthew Barnes2013-01-111-1/+1
|
* 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-3/+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().
* Add EMailFormatterPrintExtension.Matthew Barnes2012-12-081-0/+17
| | | | | This is an abstract base type for formatter extensions which are intended only for use by EMailFormatterPrint.
* e_mail_formatter_print_base_init(): Register internal extension types.Matthew Barnes2012-12-081-1/+8
|
* Make EMailPartList thread-safe.Matthew Barnes2012-12-081-6/+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-10/+10
| | | | | Replace the individual components of an EMailPartList with a reference on the EMailPartList itself in EMailFormatContext. Easier to manage.
* Coding style and whitespace cleanup.Matthew Barnes2012-11-111-8/+13
|
* Fix a memory leak in EMailFormatterPrintDan Vrátil2012-07-171-0/+2
|
* Coding style and whitespace cleanup.Matthew Barnes2012-06-251-7/+7
|
* Mail formatter rewriteDan Vrátil2012-06-061-0/+266
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.