| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
| |
Please proof-read it and tell me what needs to be improved. I assume
most people will probably not use the QWebChannel directly. Rather, they
will only consume its features indirectly through the integration in
QtWebKit/QtWebEngine. Thus the documentation here is for QWebChannel as
a library. User-end documentation should be added to QtWebKit, I think.
Change-Id: I259c204e24331271b8dc74ea11695988234a79d3
Reviewed-by: Jerome Pasion <jerome.pasion@digia.com>
|
| |
|
|
|
|
|
|
|
|
|
| |
This assimilates the JavaScript side to the QML/C++ side. We get rid
of the automagic WebSocket code. Instead, users pass in the WebSocket
from the outside, if they want to use that for communication. In the
QtWebKit/QtWebEngine cases, we will pass in our custom IPC objects.
Change-Id: I15e15b5130f99dc8b39dfbfa8cd3d8b2d34dbbc0
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@digia.com>
Reviewed-by: Lutz Schönemann <lutz.schoenemann@basyskom.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch removes the obsolete API support to send raw messages using
a QWebChannel. Instead, it is encouraged to directly use WebSockets or
navigator.qt.
By doing so, we can cleanup the code considerably. While at it, the
transport API is adapted to work on QJsonObject messages, instead of
QStrings. This will allow us to use more efficient formats in e.g.
QtWebKit or QtWebEngine. One could also implement a JSONRPC interface
using a custom transport then.
Change-Id: Ia8c125a5558507b3cbecf128a46b19fdb013f47b
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@digia.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The utility QWebChannelAbstractTransport implementation based on the
QtWebSocket has no big value. Instead, it would pull in the QtWebSocket
link-time dependency into QtWebKit/QtWebEngine, which is not desired.
Considering that the WebSocket usecase is minor, and only few people
will ever use it, we agreed that having the code in the example alone
is enough.
Change-Id: Ica038329a1d684f33e805fc296e9dff71b1446ba
Reviewed-by: Jocelyn Turcotte <jocelyn.turcotte@digia.com>
Reviewed-by: Pierre Rossi <pierre.rossi@gmail.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a quite big changeset, but necessary to get the roadmap
implemented that was discussed at QtCS.
With this patchset landed, the QWebChannel does not depend on
QtWebKit anymore, not even for the tests. Rather, we will introduce
the dependency in the other way (i.e. QtWebKit will optionally use
QtWebChannel if available).
For the pure Qt/C++ use-case, we ship a utility implementation of
a QWebChannelAbstractTransport that uses a QWebSocket for the
server-client communication. This way, we can get rid of the custom
WebSocket implementation.
The tests are refactored to run the qwebchannel.js code directly
inside QML. Integration tests for QtWebKit/QtWebEngine as well
as examples will be added to these repositories.
Change-Id: Icc1c1c5918ec46e31d5070937c14c4ca25a3e2d6
Reviewed-by: Pierre Rossi <pierre.rossi@gmail.com>
|
| |
|
|
|
|
|
|
| |
The transport interface should outlive the web channel or unregister
itself before being destroyed.
Change-Id: I77eaa26a4e1985d83cc3f19d07830cf0ca48ee7c
Reviewed-by: Simon Hausmann <simon.hausmann@digia.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This enables us to optionally use navigator.qt instead of a WebSocket,
which is nicer setup-wise and is also slightly faster:
navigator.qt:
284.0 msecs per iteration (total: 2,840, iterations: 10)
WebSocket:
295.8 msecs per iteration (total: 2,959, iterations: 10)
The baseline is ca. 203 msecs, which would mean a performance boost
of ca. 12.7%.
Furthermore, this sets the fundation to eventually add a WebEngine
transport mechanism. The WebViewTransport should also be removed and
instead the WebView itself should directly implement the
WebChannelTransportInterface.
Change-Id: I368bb27e38ffa2f17ffeb7f5ae695690f6f5ad21
Reviewed-by: Simon Hausmann <simon.hausmann@digia.com>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Some tests referenced Nokia in their license even though that was never
the case. The tests where written completely by me after Qt Nokia times.
What is missing are the examples which are still mostly original work
by Noam back then in Nokia times. The rest was (re-)written by me
completely since then anyways.
Change-Id: Ib423fb3459bcc1f7464a02de4fd82ddfd614d282
Reviewed-by: Simon Hausmann <simon.hausmann@digia.com>
|
| |
|
|
|
|
|
|
|
|
|
| |
This is achieved by hiding the MetaObjectPublisher completely as
private API. The QWebChannel is the only publisher API and now handles
both the socket as well as the publisher internally.
This now allows us to create a proper QML api in the new QmlWebChannel.
Change-Id: I3096364af8485353ca9bc19df4a81a8e4552c3d7
Reviewed-by: Simon Hausmann <simon.hausmann@digia.com>
|
| |
|
|
|
|
|
|
|
|
|
| |
The code now resides in a single qwebchannel.js file and there is only
a single callback-nesting required to setup a MetaObjectPublisher
connection.
The server-side will be simplified in the next step.
Change-Id: Ib5fc77a03c2b281c61af91713411eed571ec6108
Reviewed-by: Simon Hausmann <simon.hausmann@digia.com>
|
| |
|
|
|
|
|
|
|
|
| |
When handling the destroyed signal of a QObject, the QMetaObject of the
sender() will point to the global static QObject meta object. Thus, we
also cache its signal argument types. This way, we are able to properly
handle the destroyed signal with minimum effort.
Change-Id: Iba1a3fc94d55adad178302cc847fd4285815e689
Reviewed-by: Simon Hausmann <simon.hausmann@digia.com>
|
|
|
This example shows how to use the (currently quite ugly) raw C++ API
to setup a webchannel without using QML at all. The HTML client is then
handled by the users default browser.
The example itself shows a simple chat between the HTML client and the
C++/Qt server, with a line edit for input and a text edit showing the
chat history.
Change-Id: I8baf14efb9d0c5f5880d99710cf6317fe9b887b9
Reviewed-by: Zeno Albisser <zeno.albisser@digia.com>
|
