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: EABContactDisplay 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. ECalComponentPreview 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. EMFormatHTML 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 EMFormatHTML. 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. Composer 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 code. 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 :) Bye Dan -- --------- Dan Vratil dvra...@redhat.com +420 732 326 870 d...@jabber.cz _______________________________________________ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers