Jim Nelson <[email protected]> writes: > 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.
Not sure what you mean by "via WebKitGTK", but the exactly same DOM API is available in WebKit2, but only from a Web Extension loaded by the web process. > 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. Correct. > 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. In some cases, for simple things it would be possible to use JavaScript, instead of writing a web extension. User scripts can be injected from the UI process with WebKitUserContentManager, you can run any javascript from the UI process with webkit_web_view_run_javascript(), and we are working on an API that allows to post messages from JavaScript that are sent to the UI process and exposed as signals of the user content manager. > 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. Note that the separate process model is not only for safety, but also for performance and responsiveness among other things. I understand porting apps in some cases is a it more painful, though. > 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. I don't get what you mean by via WebKitGTK, nor what the local library is. We decided not to provide IPC for the UI and web extensions communication, so that the user can use whatever they want, but also with the idea that if apps end up using mostly the same DBus code, we can eventually add some API. > 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. Hopefully the Geary UI will be more responsive and faster once you switch to WebKit2. > -- 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 -- Carlos Garcia Campos PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x523E6462
pgplKXBA1UT1z.pgp
Description: PGP signature
_______________________________________________ desktop-devel-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/desktop-devel-list
