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 <[email protected]> wrote: > On Tue, Oct 14, 2014 at 5:07 AM, Marcos ChavarrÃa Teijeiro > <[email protected]> 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 > [email protected] > https://mail.gnome.org/mailman/listinfo/desktop-devel-list _______________________________________________ desktop-devel-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/desktop-devel-list
