On Tue, 2014-10-14 at 14:44 -0400, Matthias Clasen wrote: > On Tue, Oct 14, 2014 at 1:47 PM, Jim Nelson <[email protected]> wrote: > > > 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. > > > > Michael and Robert were sticking their heads together this weekend to > see if there is a good way forward for geary's needs. Maybe they can > share the results.
The easiest way forward would be new WebKit API to allow access to the DOM from the UI process, via a proxy object that automatically routes messages between the UI and web processes. I have no doubt there are good reasons why this API doesn't exist -- probably performance, for one. Carlos? Anyway, Robert and I spent yesterday morning learning how to get a very simple example of UI process <-> web extension IPC working via D-Bus. (Well, mostly working: Robert discovered today that our example D-Bus signal is broken....) The plan was for him to publish the code on GitHub soon. The approach is similar to Epiphany's, but Vala's excellent D-Bus support should allow Geary to avoid a lot of the glue code used in Epiphany. I won't have time to work more on it for the foreseeable future, unfortunately. I think Geary is really the worst-case scenario here: a fairly large application that performs significant DOM manipulations in response to UI events, already written with the WebKit1 API. For apps that are just displaying web pages (everything not geary?) with no such compatibility concerns, porting should be relatively easy. Happy October, Michael
signature.asc
Description: This is a digitally signed message part
_______________________________________________ desktop-devel-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/desktop-devel-list
