Hi folks,

in last two weeks I've been continuing Matthew's work on WebKit branch
and finally there are some results worth sharing. And one big bad news.

The good news first: Matt has already ported EWebView and the stuff
around, EABContactDisplay and ECalComponentPreview were already ported
as well, so I at least took some care of the HTML code:

The content of the preview is split to three of four blocks. In master
the blocks are in a table layout, so that there must be one code for
horizontal and one for vertical layout. I converted these blocks to
floating <div> elements, so that when in vertical preview, when the
blocks won't fit next to each other, they are automatically displayed
below each other. Note, that when you make the vertical preview wide
enough, the "Work" and "Personal" blocks fit side by side, which looks
very good I think. This allowed me to reduce the code of HTML-generator
a lot.
I also moved some styles to a CSS file (/usr/share/evolution/%
ver/theme/webview.css) - mainly colors and font-sizes of the headers,
titles etc.
Finally, instead of re-rendering the entire HTML code when a contact
list is collapsed/expanded, I implemented the functionality in
JavaScript, which makes it faster and the code is much cleaner.

There was nothing much to do here, I just applied the stylesheet from
webview.css. The look is now consistent with look of contacts preview.

This gets ugly. WebKit does not provide any means to set content of a
resource (image, frame...) other then by settings URL of the resource to
"data:base64,base64_encoded_data". Pretty ugly. What's worse, there's
absolutely no way how to do this asynchronously (well, there is - I'll
get to it). So now the primary formatting (headers, "main" content) is
done asynchronously the old way (create HTML -> e_web_view_load_string)
and any other resource, when requested, is loaded by the method describe
above, but asynchronously (I have never run into a UI-freeze while
testing, but I can imagine that parsing some crazy 5MB large HTML email
and encoding it to base64 can take some time...). 

For now, the preview can display plain text mails, HTML mails and can
even load multipart/related subparts. 

The collapsible headers were ported to JavaScript to safe some code in

The only chance how to make EMFormatHTML completely asynchronous is to
use unstable libsoup API and create our own content handler which when a
request is send would fetch the mail part, decode it and send it as a
response. The trouble is, that I haven't found (yet!) any way, how to
pass a CamelMimeMessage to the parser (which is instantiated for each
new request), because it is nontransparent to the request sender.

Until Composer is ported, I took EWebView from master, renamed it to
EWebViewGtkHTML and updated Composer to use it instead of EWebView.
Thanks to this, I can now write this email from the webkit-Evo :) Future
plan is to take GtkHTMLEditor API, rip off it's guts and put in WebKit

WebKitGtk bug (that's the bad news)
There is a big ugly bug in WebkitGtk (see
https://bugs.webkit.org/show_bug.cgi?id=63451 ). In short, WebKit does
not render embedded GtkWidgets, so you can't see the attachment bar,
inlined-image button etc. Luckily, there is a WebKit developer sitting
in the cubicle next to mine whom I keep annoying about the bug (I've
been probably annoying him so much that he rather went on vacation, but
he should be back next week, so I'll start bugging him again :) ). What
we already know, it won't be easy fixing and will take some time. Until
a WebKit with the fix is released, the WebKit port is more or less
useless for production. I think I can have Evo ported before 3.2, but I
doubt WebKit will be fixed soon enough.

So, that's the current standing. Until the bug is fixed, I have enough
time to start digging into libsoup and make mail rendering completely
asynchronous (which will probably take me some time).

That's all for now :)



Dan Vratil
+420 732 326 870

evolution-hackers mailing list
To change your list options or unsubscribe, visit ...

Reply via email to