Evolution gets a new e-mail formatter

While porting  Evolution to WebKit, I have made some major changes in how formatting emails in Evo works. But lately I've been more and more aware, that it's not flexible enough and that there is a lot of space for improvement.

With Milan Crha we designed a proper, object-oriented (within the limits of C and GLib) parser and formatter. They are now both very flexible, easily extensible and displaying e-mails is a bit faster thanks to more asynchronous approach.

The main feature that comes out of this redesign is an extension we call text-highlighter. It uses the highlight utility to format text parts. For now we only highlight diffs and patches, but the list can easily be extended by all formats supported by highlight.

But we intend to go a bit further. We want to allow users to choose how each part should be formatted! The popup menu on each part of the email will contain a list of available (and compatible) formatters. Selecting one will reload the given part (each parts is in an <iframe> ) and render it again using specified formatter.

As far as I can tell this is a quite unique feature among e-mail clients  and hopefully it will make lives of our users a bit easier :). This particular feature is not in place yet, but it will included in Evolution 3.6.

Now I'll spend a week or so by fixing regressions that we missed during testing (quite thorough, as always when Milan tests someting :D ) and that will appear when more people start using it, After that I'll finally move over to porting the message composer to WebKit.

Stay tuned ;)

Evolution meets WebKit

Evolution is the default email client, address book and calendar application in GNOME. It has large variety of features, including support for Microsoft Exchange and Google services. But it's weak spot for some time now has been a poor email renderer. Evolution is using GtkHtml, which cannot compare to today modern HTML renderers.

And so, eight months ago, after working on Evolution for about 5 months, I took the webkit branch after Matthew Barnes and begun to dig into depths of Evolution's email formatter, parser and renderer and started porting it to WebKit. Today all the work has been merged to the main branch and Evolution made it's first step towards leaving GtkHtml behind.

So what's new?  Many things! Thanks to GObject introspection in DOM bindings we can modify the rendered emails on the fly without parsing and rendering the entire email again. This makes expanding and collapsing headers and attachments previews much faster, smoother and improves the overall user experience.

Another benefit for users is full support of CSS. While GtkHtml does not support any styles, WebKit does. This means that various newsletters and flyers are rendered correctly and with all the details. WebKit has also first-class JavaScript support, but don't be afraid. Scripts were disabled so that your emails and comfort are safe.

The invitation preview plugin has been rewritten to be completely in HTML, so it's much easier to copy text from it, while all it's functionality remains preserved (using DOM bindings again). It also makes it possible to print the invitations and events previews.

When I was rewriting the formatter, I have also looked on printing. Print-outs now look fresher, are better formatted and the content is better structured. I have also added a brand new feature, which allows you to select which email headers and in which order should printed. This option is available directly in the printing dialog, in "Headers" tab.

Printout from Evolution 3.2 Printout from WebKit-based Evolution Preview of headers configuration in printing dialog

The port is ready for daily use, but there might still be bugs hiding at various places. Therefor the changes we merged so early after 3.4.0 release, so that we have enough time before 3.5.1 to catch them all and at least 6 months until 3.6 stable release to make sure that everything is perfectly in place.

And what's going to happen next? I will now start porting the email composer to WebKit. If things go well and smoothly, I might make it to have it in Evolution 3.6 this Autumn and thus getting rid of GtkHtml once and for all.