[webkit-qt] QtQuick QML API for WebKit1

[Alberto Mardegan]

On 03/12/2013 11:44 AM, Simon Hausmann wrote:
> On Wednesday, February 13, 2013 04:47:55 PM Alberto Mardegan wrote:
>> Hi all!
>>    I plan to spend some time on building a QtQuick (Qt5) plugin for WebKit1.
>> There are several reasons why I want to do this, the main ones being the
>> possibility of playing with the cookie jar and having direct access to the
>> DOM.
[...]

> I'm going to use the opportunity to give some feedback :)

Thanks, that's really appreciated. :-)
Below I'll use "WebKit1" when referring to "single-threaded WebKit code
paths" just because it's shorter.

[...]
> For compatibility we do have to keep the single-threaded WebKit code paths 
> around (aka QWebPage/QWebView in Qt), but with my Qt project module maintainer 
> hat on I would welcome efforts to _reduce_ the maintenance of that instead of 
> adding to it. We should streamline our efforts and work on the same things.

Agreed. I surely don't intend to bring more maintenance burden on the
shoulders of QtWebKit developers, and it was implicit that I would be
responsible for any maintenance effort on the code I might alter.
That said, I can understand perfectly if you don't find this
precondition to be satisfactory at all, and on the contrary would simply
like to see the WebKit1-related code base shrink, rather than getting
bigger, regardless of who is maintaining it.
I'll explain my reasons to use WebKit1 when answering to your points
below; I can certainly be convinced that this WebKit1 effort is not
worth or useless, but let me anyway describe a possible scenario around it:

> Consequently with that information at hand I'm not in favour of having a 
> QtQuick2 integration that is based on the single-threaded WebKit in the 
> upstream source tree. We need some better arguments on the table :)

I believe it's possible to change QWebPage/QWebFrame so that they would
not require the view to be a QWebView/QGraphicsWebView, but any QObject
implementing an extremely simple interface which allows the QWebPage to
ask the view for a QWebPageClient object.
The goal would be to get:
  libQt5WebKitWidgets.so (QWebView, QGraphicsWebView, QWebInspector)
  -> libQt5WebKitSingleThread.so (QWebPage, QWebFrame,
                                  QWebViewInterface)
  -> libQt5WebKit.so (nearly the current one)

where the libQt5WebKitSingleThread.so would basically contain the
QtWidget-less parts of the current WebKitWidgets library.
So, both libQt5WebKitWidgets.so and a new libQt5WebKit1Quick.so
libraries could use the single threaded API, but wouldn't need to reside
in QtWebKit's source tree. So, at the end, if the WebKitWidget part is
moved out, the overall code base in the QtWebKit repository would
actually be reduced.
BTW, I'm still studying the feasibility of all this without breaking the
ABI (libQt5WekBitWidgets still will need to provide the QWebPage and
QWebFrame classes), so it's all a bit vague at the moment.
But if this was implemented without breaking API/ABI for QtWebKitWidgets
clients, would you object that in principle?

> As mentioned in earlier mails, I would much rather welcome efforts to make the 
> use-cases work that you're interested in in the world of WebKit2. There's 
> nothing inherent in a process separation that makes things like DOM access 
> impossible. It just works slightly differently. For example by writing the code 
> to traverse the DOM in JavaScript and running it as part of that big event 
> loop. Extract the information you need and pass it back to the application.

Yes, this should work and solve one of my use-cases. But the main
feature I lack is having a different cookie-jar per web view, so that I
can login with multiple Facebook accounts at the same time, and keep
those sessions completely separate.
As I understand this is not implemented, and I got the impression that
such task, considering both that I'm new to WebKit and all the
stakeholders involved, might take ages. Though indeed, that would be the
ideal solution.
Any help in leading me to a solution is greatly appreciated, and as far
as I'm concerned would make any effort on the WebKit1 QtQuick bindings
unnecessary.

> I recently learned that the KDAB folks apparently have had success with doing 
> simple QObject bindings across process boundaries. With reasonable contraints 
> that are documented (properties would be value cached, so don't expose heavy 
> content for example) that might be a workable alternative to make hybrid use-
> cases easier.

I'm not sure that I could make use of this. I'm afraid that the cookie
issue would be better solved by implementing it in WebKit2 itself.

Ciao,
  Alberto


-- 
http://blog.mardy.it <- geek in un lingua international!