Just to jump in, the situation we're facing with Geary is that Geary
works fairly intimately with the WebKit DOM.  For example, we
programmatically inject HTML elements while building the page and even
in response to user events after the page has been rendered.  In
WebKit 1 this was no problem as the entire DOM was available via
WebKitGTK.

In WebKit 2, the page is rendered by a separate process and the DOM is
unavailable to the parent process.  As I understand things, we need to
write a .so and instruct the rendering process to load it for our
HTML.  In turn, that .so is in-process and has full access to the DOM.
The .so then needs to offer some kind of IPC -- D-Bus would be perfect
for this -- that allows for Geary to communicate DOM updates.  This is
also how we can be informed of user input.

Since we use WebKit to compose mail as well, that's going to have be
refactored too, probably with a separate IPC as our needs with the
composer are entirely different than the message viewer.

This is a major refactoring of Geary.  I imagine almost any
application that does anything more than displaying static HTML will
run into similar problems.

I should add that the separate process model of safety is not really a
big benefit for us.  We run with JavaScript and plug-ins disabled.  We
rarely if ever get WebKit crashes reported to us.

It would be great if the DOM was available via WebKitGTK and the local
library did the IPC for us, but I've been told that that's not going
to happen.  The DOM is a huge API and I can't blame them for that.  I
do wish the separate process model was an optional run mode because,
as I said, I don't see a lot of benefits moving to it for Geary.

-- Jim

On Tue, Oct 14, 2014 at 3:24 AM, Matthias Clasen
<matthias.cla...@gmail.com> wrote:
> On Tue, Oct 14, 2014 at 5:07 AM, Marcos Chavarría Teijeiro
> <chavarria1...@gmail.com> wrote:
>> Hi!
>>
>> I'm working on porting Yelp to WK2 as part of an Igalia internship [1]
>> and in addition I'm creating a some kind of tutorial/cookbook to help
>> people to port WK1 app to WK2.
>>
>> You cand find the tutorial (it's a work in progress) here [2]. I hope
>> it can help...
>
> Fantastic, thanks. I've added a link to the wiki page.
> _______________________________________________
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Reply via email to