aboutsummaryrefslogtreecommitdiffstats
path: root/em-format/e-mail-extension-registry.h
Commit message (Collapse)AuthorAgeFilesLines
* Bug 721545 - License text contains obsolete FSF postal addressMatthew Barnes2014-01-081-10/+9
|
* Teach EMailExtensionRegistry to find extensions.Matthew Barnes2013-02-011-4/+5
| | | | Restore this commit with a proper bug fix to follow.
* Revert "Teach EMailExtensionRegistry to find extensions."Milan Crha2013-01-291-5/+4
| | | | | | | | | | 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.
* Teach EMailExtensionRegistry to find extensions.Matthew Barnes2012-12-081-4/+5
| | | | | | | | | | | | | | | | | | | | | 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().
* EMailExtensionRegistry cleanups.Matthew Barnes2012-12-081-25/+25
|
* Remove EMailExtension.Matthew Barnes2012-12-081-17/+16
| | | | | | | | | | | | 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.
* Mail formatter rewriteDan Vrátil2012-06-061-0/+156
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.