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 > [email protected] > http://lists.qt-project.org/mailman/listinfo/development > _______________________________________________ > Development mailing list > [email protected] > http://lists.qt-project.org/mailman/listinfo/development -- Qt Developer Days 2014 - October 6 - 8 at BCC, Berlin Milian Wolff | [email protected] | 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 _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
