aboutsummaryrefslogtreecommitdiffstats
path: root/modules/text-highlight/e-mail-formatter-text-highlight.c
Commit message (Collapse)AuthorAgeFilesLines
* Bug 708390 - text-highlight: Don't interfere with printingMatthew Barnes2013-10-011-27/+2
| | | | | | | The text-highlight module is for enhancing the *display* of textual email parts. It should not interfere at all when printing an email. (cherry picked from commit 169ec754ae991e0bd3975ee89e6110f1a0a8d841)
* Bug #706008 - Workaround gnome-shell style change on focus changeTomas Popela2013-09-121-8/+3
| | | | | | | 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_ref_mime_part().Matthew Barnes2013-05-201-6/+15
|
* Add e_mail_part_get_id().Matthew Barnes2013-05-201-2/+4
|
* em-format cleanups.Matthew Barnes2013-05-201-31/+39
|
* [EMailFormatter] Use GdkRGBA and GtkStyleContext to get theme colorsMilan Crha2013-04-231-2/+2
| | | | | | | | | | 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-42/+19
| | | | | | | | 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.
* Use CamelMimeFilterToHTMLFlags enum type where appropriate.Matthew Barnes2013-02-071-2/+2
|
* Teach EMailExtensionRegistry to find extensions.Matthew Barnes2013-02-011-41/+0
| | | | Restore this commit with a proper bug fix to follow.
* Revert "Teach EMailExtensionRegistry to find extensions."Milan Crha2013-01-291-0/+41
| | | | | | | | | | 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.
* Bug #692005 - Changing character encoding doesn't workMilan Crha2013-01-191-0/+10
|
* Bug 691133 - Evolution creates 'highlight' zombiesMatthew Barnes2013-01-041-8/+13
| | | | | | | | | | | Evolution spawns the 'highlight' program with these flags: G_SPAWN_SEARCH_PATH G_SPAWN_DO_NOT_REAP_CHILD G_SPAWN_SEARCH_PATH is not needed because configure already determines the absolute path to the 'highlight' program. G_SPAWN_DO_NOT_REAP_CHILD results in zombie 'highlight' processes. Remove both flags.
* Teach EMailExtensionRegistry to find extensions.Matthew Barnes2012-12-081-41/+0
| | | | | | | | | | | | | | | | | | | | | 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-21/+11
| | | | | | | | | 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-38/+46
| | | | | | | | | | | | 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-7/+1
| | | | | | | | | | | 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.
* Make EMailPartList thread-safe.Matthew Barnes2012-12-081-2/+2
| | | | | | 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-1/+6
| | | | | Replace the individual components of an EMailPartList with a reference on the EMailPartList itself in EMailFormatContext. Easier to manage.
* Don't rely on user's $PATH, use HIGHLIGHT_COMMAND defined by configureDan Vrátil2012-10-091-1/+1
|
* Bug #684447 - Check for highlight during configure.Dan Vrátil2012-10-091-31/+54
| | | | | | | | | | | | | | If the highlight program cannot be found width AC_PATH_PROGS, configure will abort with an error message. You can either a) install highlight b) specify the patch with HIGHLIGHT=/path/to/highlight c) pass --disable-text-highlight to configure to exclude the module This also makes text-highlight module to fallback to text/plain formatter when highlight program would crash or fail to ensure the content is delivered to user.
* portability: don't use too generic variable namesAntoine Jacoutot2012-10-041-4/+4
| | | | | | | OpenBSD (and maybe other OS) already declare stdout and stdin in <stdio.h> which breaks evolution build, so prefix both with "pipe_" to prevent clashing. https://bugzilla.gnome.org/show_bug.cgi?id=685471
* Bug #680786 - [text-highlight] Correctly display binary patchesDan Vrátil2012-08-231-6/+19
|
* Coding style and whitespace cleanup.Matthew Barnes2012-08-201-6/+7
|
* Bug #680786 - [text-highlight] Prefer Content-Type header over file name ↵Dan Vrátil2012-08-101-14/+18
| | | | extension
* Bug #680634 - Missing image attachmentDan Vrátil2012-07-271-7/+8
|
* Highlighting of text parts and source codesDan Vrátil2012-07-251-0/+391
This adds 'Format as' submenu to the preview pane context menu. The submenu is available only for text/plain parts or parts with a source code (we support about 40 various types). Using the 'highlight' utility, the formatter processes the part and highlights the source code it contains. (discussion in bug #680026)