I've been on vacation and so I'm catching up with this thread.
I've looked over Robert's github branches and am still on the fence.
I'm always going to lean toward the "engineered" solution, and at this
moment that would be the D-Bus approach.
To respond to some points made in this thread so far:
I agree with Shaun: the WebKit 2 API changes seem geared for web
browsers, not the plethora of applications now relying on WebKit.
Someone mentioned improved UI responsiveness and performance with the
new model, but again, just as WebKit stability hasn't been a big issue
for us, neither is performance.
Let me put it this way: if we were starting Geary *today* and saw how
WebKit 2 required us to interact with the rendering process, I would
look around for another embedded HTML viewer/editor solution before
adopting it. This change is akin to SQLite moving to a
separate-process model: a lot of work on our part for little to no
appreciable benefit.
That said, it appears the boat has left the dock, so I'll wrap up my
complaints there.
As far as proxying the DOM, I suspect the real performance problems are
not in individual operations but operations involving iteration. (In
other words, inserting a single DIV isn't an issue, but walking the
tree looking for all DIVs of a certain class is.) We do iterations in
a few places, so we'd have to be cognizant of that.
If WebKitGTK proxied the most-used subset of DOM operations and let the
application write its own WebExtension for custom and
performance-sensitive operations, that would go a long way toward
lessening the collective pain. Then again, maybe it's only Geary and
Evolution that suffer this pain and we should just man up and do the
port.
-- Jim
_______________________________________________
desktop-devel-list mailing list
[email protected]
https://mail.gnome.org/mailman/listinfo/desktop-devel-list
