summaryrefslogtreecommitdiff
path: root/src/webchannel/webchannel.pro
Commit message (Collapse)AuthorAgeFilesLines
* consistently put {qt,qml}_{module,plugin} at the end of project filesOswald Buddenhagen2016-02-251-2/+2
| | | | | | | | this fixes static builds by ensuring that all dependencies are exported. Task-number: QTBUG-51071 Change-Id: Ibf63974f6b989abb6c7967a74ff770af09bab114 Reviewed-by: Milian Wolff <milian.wolff@kdab.com>
* Compile when QML is disabled5.5Andy Shaw2015-09-291-0/+2
| | | | | | | | | | Since QJSValue is part of the QML module then it should check if that is available before using it so we add a QT_NO_JSVALUE define to help with this. Task-number: QTBUG-46850 Change-Id: I1974518a5c134dbb8508a46505b43c820a7a700a Reviewed-by: Liang Qi <liang.qi@theqtcompany.com>
* Remove obsolete conversion work-around.5.4.0Milian Wolff2014-10-171-1/+0
| | | | | | | | | The conversion from QJSValue to QJsonArray seems to work just fine with Qt 5.4. Originally, this work-around was introduced to fix the QML tests, which still pass without this code now. Change-Id: Id52a5a16ebe25914f01d597778152e0595c9f1f4 Reviewed-by: Lars Knoll <lars.knoll@digia.com>
* Add documentation for the QtWebChannel module.Milian Wolff2014-08-011-0/+2
| | | | | | | | | | | 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>
* Make the QWebChannel QML API publically accessible.Milian Wolff2014-07-151-1/+11
| | | | | | | | | | This is required for proper QtWebKit/QtWebEngine integration, as otherwise these modules would have to redo a lot of the QtWebChannel QML API. Furthermore, without this, we could not use the WebChannel.id attached property everywhere, independent of the web browser technology. Change-Id: I032a9326841d505c2f77959a240bbfc71e94b6e8 Reviewed-by: Sean Harmer <sean.harmer@kdab.com>
* Do not link against QtNetWork.Milian Wolff2014-07-041-1/+1
| | | | | | | It is not required anymore. Change-Id: Ifb76ed515193591a09a81b73edee12703d16d04c Reviewed-by: Jocelyn Turcotte <jocelyn.turcotte@digia.com>
* Only depend optionally on QtWebSockets, and only use it in the example.Milian Wolff2014-07-041-5/+3
| | | | | | | | | | | | | 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>
* Refactor code to use QWebChannelAbstractTransport and QtWebSockets.Milian Wolff2014-07-041-4/+4
| | | | | | | | | | | | | | | | | | | | | | 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>
* Merge QWebChannelSocket and QWebSocketTransport.Milian Wolff2014-03-211-2/+1
| | | | | | | | | The former was just the private implementation of the latter. This way, the code structure is more understandable to newcomers and follows existing best-practices. Change-Id: I07cf64370553f4c2de349b5f01e90b31112fee58 Reviewed-by: Simon Hausmann <simon.hausmann@digia.com>
* Port code to QtWebSockets.Milian Wolff2014-03-061-3/+1
| | | | | | | | | | | | | This removes the custom WebSocket server implementation and replaces it by a dependency on the QtWebSockets module. Sadly, the QtWebSocket module does not yet support custom protocols. Also, there is quite some boiler plate code required, something which I want to simplify upstream in the QtWebSockets module later. Change-Id: I8066418fb1857d23b8593c443bc9a98ded917a99 Reviewed-by: Kurt Pattyn <pattyn.kurt@gmail.com> Reviewed-by: Frederik Gladhorn <frederik.gladhorn@digia.com>
* Make the underlying transport mechanism of the webchannel pluggable.Milian Wolff2014-02-061-2/+5
| | | | | | | | | | | | | | | | | | | | | 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>
* Fix regression in handling of var-emitting signals from QML.Milian Wolff2014-01-091-0/+5
| | | | | | | | | | | | Qt 5.3 propagates var-arguments of signals as QJSValue instead of as a QVariant. This then fails to be serialized to QJson, failing our unit tests. Now, QJSValue types are manually casted to QJsonValues which makes the tests pass again. Change-Id: I730c595eee214ebe3d1f83009cd5605f66407f55 Reviewed-by: Simon Hausmann <simon.hausmann@digia.com>
* Simplify usage of QWebChannel on the server side.Milian Wolff2014-01-081-3/+6
| | | | | | | | | | | 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>
* Simplify QWebChannel usage by merging webchannel.js and qobject.js.Milian Wolff2014-01-081-2/+1
| | | | | | | | | | | 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>
* Restructure sources and assimilate to Qt module structure.Milian Wolff2013-12-121-0/+28
This module can hopefully be done in time for 5.3. This commit changes the source structure and QMake files to adapt to typical Qt modules. With this in place, we can now use QT += webchannel in qmake files to link against the pure Qt/C++ QtWebChannel library. The QML plugin is separated from it and can be loaded optionally, if the quick module could be found. Also added is now a qmlplugindump for tooling integration. Note that the Qt.labs namespace is removed. The test file structure is also adapted to how its done in the QtDeclarative module. Note that this setup apparently does not support to run tests without running make install first. Change-Id: I1c15d72e7ab5f525d5a6f651f4e965ef86bc17bd Reviewed-by: Simon Hausmann <simon.hausmann@digia.com>
View Lorry Controller Status