aboutsummaryrefslogtreecommitdiffstats
path: root/em-format/e-mail-formatter-text-enriched.c
Commit message (Collapse)AuthorAgeFilesLines
* Don't close base stream when destroying a CamelFilterOutputStream.Matthew Barnes2014-03-111-0/+2
| | | | | | | | | | | | | | | GFilterOutputStream, from which CamelFilterOutputStream is derived, defaults to closing its base stream when the instance is finalized. That makes sense in the general case, but CamelFilterOutputStreams are usually temporary wrappers on a more permanent base stream, so we need to remember to override the default "close-base-stream" property value. I was tempted to just make CamelFilterOutputStream override the default automatically, but I decided against it because my long term plan is to drop CamelFilterOutputStream for GConverterOutputStream which also does not override the "close-base-stream" default. The closer the semantics of the two classes match, the easier porting will be in the future.
* EMailFormatter: Use GOutputStream instead of CamelStream.Matthew Barnes2014-03-011-18/+17
|
* Bug 721545 - License text contains obsolete FSF postal addressMatthew Barnes2014-01-081-10/+9
|
* Miscellaeous cleanups.Matthew Barnes2013-10-201-1/+1
|
* Bug #706008 - Workaround gnome-shell style change on focus changeTomas Popela2013-09-121-10/+4
| | | | | | | Avoid redrawing (thus loosing the selection and scroll position) of preview window on style change by defining the colors through CSS styles. On style change we just update the CSS color definitions and preview will update itself without redraw.
* Add e_mail_part_get_mime_type().Matthew Barnes2013-05-201-2/+4
|
* [EMailFormatter] Use GdkRGBA and GtkStyleContext to get theme colorsMilan Crha2013-04-231-3/+3
| | | | | | | | | | 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.
* Add a priority field for mail formatter and parser extensions.Matthew Barnes2013-02-011-0/+1
| | | | | | | | | | | Add a priority field to EMailFormatterExtension and EMailParserExtension class structs. Extension classes can then explicitly specify a priority with respect to other extension classes with the same MIME type, so that the order of extension registration doesn't matter. Priority field defaults to G_PRIORITY_DEFAULT. Built-in formatters and extensions will use G_PRIORITY_LOW. We can get more sophisticated with priority values if we need to, but this should suffice for now.
* Teach EMailExtensionRegistry to find extensions.Matthew Barnes2013-02-011-1/+2
| | | | Restore this commit with a proper bug fix to follow.
* Revert "Teach EMailExtensionRegistry to find extensions."Milan Crha2013-01-291-2/+1
| | | | | | | | | | 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-5/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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/+2
| | | | | | | | | | | | | | | | | | | | | 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().
* EMailFormatterExtension: Convert get_description() to a string field.Matthew Barnes2012-12-081-7/+1
| | | | | | 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.
* EMailFormatterExtension: Convert get_display_name() to a string field.Matthew Barnes2012-12-081-7/+1
| | | | | | 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.
* Convert EMailFormatterExtension to an abstract class.Matthew Barnes2012-12-081-30/+14
| | | | | | | | | 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.
* Remove EMailExtension.Matthew Barnes2012-12-081-11/+1
| | | | | | | | | | | | 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.
* EMailExtension: Replace mime_types() method with a string array.Matthew Barnes2012-12-081-10/+6
| | | | | | | | | | | 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.
* Coding style and whitespace cleanup.Matthew Barnes2012-11-111-1/+2
|
* Coding style and whitespace cleanup.Matthew Barnes2012-08-201-1/+1
|
* Coding style and whitespace cleanup.Matthew Barnes2012-06-251-1/+1
|
* Reduce usage of g_type_class_peek_parent().Matthew Barnes2012-06-251-1/+0
| | | | G_DEFINE_TYPE macros define a static "parent_class" variable.
* Mail formatter rewriteDan Vrátil2012-06-061-0/+154
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.