25.01.2012, 15:09, "Sylvain Pointeau" <[email protected]>: > On Tue, Jan 24, 2012 at 7:28 PM, Jocelyn Turcotte > <[email protected]> wrote: >> Hi Sylvain, >> >> This might take some time, but we will eventually need some way to exchange >> data between wrapping applications and the web content. >> It might not be as powerful as QWebElement was, but it should cover most use >> cases for those distributing and controlling both the web content and the >> wrapping C++/QML application. >> >> See also No'am's post about the subject: >> http://labs.qt.nokia.com/2011/08/31/an-oldnew-approach-to-qtwebkit-hybrid/ >> >> I think that WebKit1 offers few advantages over WebKit2 as a platform web >> view, especially from a user experience and stability point of view. Of >> course there will always be cases where WebKit1 will feel more adapted, but >> we'd like to see the list of those cases to shrink over time as WebKit2's >> advantages start weighting more (especially with the Qt5 scene graph). >> >> Having multi processes should bring only a reasonable overhead and, if this >> becomes a problem, we keep the possibility of working on getting the web >> "process" spawned in a thread instead. >> >> I hope this clears it a bit, >> Jocelyn > I am still not clear of the real benefit in case of embedding webkit2 in an > app. > Seems it is more efficient for the scene graph (of QML), but I do not know > why... > Also I am wondering why apple is keeping webkit1 as web view for application > if they use webkit2 for Safari. > Does it means they think that webkit1 is more suitable for normal apps?
AFAIK, they just want to preserve compatibility with existing applications. WebKit2 architecture allows to expose both WebKit1 and WebKit2 APIs from single build of WebKit, so it's not a big deal to keep both APIs. -- Regards, Konstantin _______________________________________________ webkit-qt mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-qt
