Jim Nelson <jim yorba org> 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 <matthias clasen gmail com> wrote:On Tue, Oct 14, 2014 at 5:07 AM, Marcos ChavarrÃa Teijeiro <chavarria1991 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
-- Carlos Garcia Campos PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x523E6462
Attachment:
pgpEzxYcZd3Sw.pgp
Description: PGP signature