[Development] Qt WebChannel 5.5 roadmap: WebEngine, QtWebView

[Milian Wolff]

On Wednesday 27 August 2014 14:49:08 Hausmann Simon wrote:
> I'm pretty sure that all the "native" webview APIs allow for at least
> runJavascript(string), so injection may also be an easier option.

Oh nice, I assumed without testing nor reading code that the QtWebView API 
would be very minimal and thus not even supply such an API. If it does exist 
then yes, I think just injecting the qwebchannel.js contents and a simple 
schim to setup the WebSocket would be best.

Bye

>   Opprinnelig melding
> Fra: Jocelyn Turcotte
> Sendt: 16:45 onsdag 27. august 2014
> Til: Milian Wolff
> Kopi: Development
> Emne: Re: [Development] Qt WebChannel 5.5 roadmap: WebEngine, QtWebView
> 
> On Wed, Aug 27, 2014 at 04:27:35PM +0200, Milian Wolff wrote:
> > Hey all,
> > 
> > for Qt 5.4, the new WebChannel module will only be "easily" usable for
> > WebKit users. For 5.5 I plan to add WebEngine integration, if Pierre is
> > not beating me to it. We will simply copy the QML API, and no changes on
> > the client-side HTML should be required, I think.
> > 
> > Then, recently, QtWebView was announced for Android and iOS WebViews. I
> > wonder if we can integrate the WebChannel nicely there as well.
> > Instantiating a WebChannel internally won't be the problem, nor copying
> > the QML API. But for HTML clients, I don't know if one can automatically
> > setup the transport mechanism (based on WebSockets), nor whether one can
> > even load the qwebchannel.js API via a qrc URL. Can someone working on
> > QtWebView shed some light here please?
> 
> One thing that WebSockets do is that they are a transport layer on top of
> HTTP. You can transport your qwebchannel.js or any html hook through a
> non-upgraded WebSocket's HTTP response.
> 
> QtWebSocket doesn't support this at the moment and simply ignores any HTTP
> request not asking for an upgrade, but I had a simple change that was
> manually writing the HTTP response on the QTcpSocket and it worked pretty
> well.
> 
> The main issue is that you normally have websocket as part of an HTTP
> server and not the other way around, so we'd have to stretch the API a
> bit. I was able to hack it quickly by reusing QNetworkRequest and
> QNetworkReply but we should probably duplicate their interface into some
> kind of QWebSocketHttpRequest/Reply if we don't want to poison
> QNetworkAccessManager's API with foreign use cases.
> 
> Cheers,
> Jocelyn
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-- 
Qt Developer Days 2014 - October 6 - 8 at BCC, Berlin

Milian Wolff | milian.wolff at kdab.com | Software Engineer
KDAB (Deutschland) GmbH&Co KG, a KDAB Group company
Tel. Germany +49-30-521325470, Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-independent software solutions