| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
| |
No other changes seem to be required.
Change-Id: Ie15639f74f09cbd303828c96f75d29283ec4d562
Reviewed-by: Arvid Nilsson <anilsson@blackberry.com>
Reviewed-by: Chris H-C <chutten@blackberry.com>
Reviewed-by: Pierre Rossi <pierre.rossi@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This includes two optimizations which have been forgotten to be
upstreamed before:
a) For the common case of property notify signals named "...Changed",
the string name is now not send anymore to the client. Instead, these
cases are special-cased and constructed on the fly. This drastically
reduces the size of Qt.init responses and property update messages.
b) Furthermore, do not list signals as methods, further reducing the
size of Qt.init response messages.
Together this shows a noticeable reduce of CPU instructions in the
benchmarks as recorded with perf:
benchmark_classInfo: down ~10%
benchmark_initializeClients: down ~2%
benchmark_propertyUpdates: down ~1%
Change-Id: I01e59f5c1dceedb893f7a3e3e127acb493baaa7f
Reviewed-by: Michael Bruning <michael.bruning@digia.com>
Reviewed-by: Pierre Rossi <pierre.rossi@gmail.com>
|
|
|
|
|
|
|
|
|
| |
Instead of initializing the property maps in Component.onCompleted, use
"var foo: ({})" instead. This looks suprising, but the "var foo: {}"
syntax won't work - it's an empty binding expression closur, not a map.
Change-Id: I9edeeeeeabb3a871a46d8bb8a991a4155040497a
Reviewed-by: Zeno Albisser <zeno.albisser@digia.com>
|
|
|
|
|
|
|
|
|
|
|
| |
For performance reasons, we group property updates and send a single
batch update notification. This is now tested to work as intended.
This also uncovered a bug in webchannel.js when multiple functions
subscribe to the same id.
Change-Id: Ic8648d664dd1fe54df7e25fade6a6088386af992
Reviewed-by: Zeno Albisser <zeno.albisser@digia.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This tests the functionality of publishing a plain QtObject from
QML to the HTML client.
It tests property binding, i.e. reading and writing of an objects
property on the client side, as well as change notification tracking.
Furthermore a server-side method is invoked from the client and
signal submission from the server to the client is tested.
Change-Id: I62e544cddf4483b57535a9bc1e05a36105ec6622
Reviewed-by: Zeno Albisser <zeno.albisser@digia.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This removes a lot of obsolete files and simplifies the build system
of the examples.
Furthermore, the examples can now be run without running make install
first. It reuses the same import path as the test does.
Note that the examples are not installable anymore now though. If this
is required, it can be added again.
Change-Id: Ic7ff80f734b035a03fb1a11a2df492c97298ceff
Reviewed-by: Zeno Albisser <zeno.albisser@digia.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
This uncovered a bug in webchannel.js, which stringified strings leading
to duplicated quoting. This is also fixed now.
Furthermore, some QMake changes are required to make it possible to run
the tests without first installing QWebChannel.
Change-Id: If7e8f73a748f86f2d5c7d39000e90612367038af
Reviewed-by: Zeno Albisser <zeno.albisser@digia.com>
Reviewed-by: Pierre Rossi <pierre.rossi@gmail.com>
|
|
|
|
|
| |
Change-Id: Idf344f46aa09a13dfe4db00203b7644006fbf944
Reviewed-by: Pierre Rossi <pierre.rossi@gmail.com>
|
|
|
|
|
|
|
|
| |
This is required for factory-like methods on the C++/QML side,
which we want to access from the HTML side as well.
Change-Id: I2852bbc9c8effb6d6f49b5be784241a6e2320823
Reviewed-by: Pierre Rossi <pierre.rossi@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a big code drop - sorry for that. The benefits are worth it
though, I'm sure. The optimizations were required to make the
WebChannel useable even on a low-end embedded device with medium
amount of traffic.
The changes in this patch can be grouped into different parts:
a) Do more in C++: Esp. by leveraging e.g. the new classInfoForObjects
in QtMetaObjectPublisher (on the C++ side) one can greatly reduce
the time required for initialization of the webchannel.
b) Property Caching: Instead of requiring a socket roundtrip whenever
a property is read on the HTML side, we now cache the property values
on the HTML side. Note that for this to work properly, one needs to
add proper notify signals to the property declarations, as otherwise
the cache will not get updated.
c) Grouping: Instead of sending separate messages to the clients
for every property update, these signals are grouped by a 50ms timer,
and then send aggregated to the client. This reduces the socket
traffic, as more boiler plate can be shared.
d) Compression: Some data was previously send repeatedly, such as
property name and notify signal. This is now compressed internally
where possible (i.e. for the ${propName}Changed naming scheme).
e) Message Flood Prevention: Previously, one could easily flood an
HTML client by sending data to it. If it could not work off the
incoming stream one would freeze the HTML client. Now, we wait for an
idle signal of the client prior to sending new data to it. Paired
with the message grouping and property cache mentioned above, we
are able to only send the newest data once the HTML client becomes
active again. I.e. we discard now-obsolete property updates etc.
Change-Id: I8f3ae16ed6c1f6a89b644acdce7efbf0f07fc786
Reviewed-by: Pierre Rossi <pierre.rossi@gmail.com>
|
|
|
|
|
| |
Change-Id: Idd32243173775ec49b4a51a55faa85e47e11a4f1
Reviewed-by: Pierre Rossi <pierre.rossi@gmail.com>
|
|
|
|
|
| |
Change-Id: I47345fc52677b68ae75d018484b495fc81949054
Reviewed-by: Pierre Rossi <pierre.rossi@gmail.com>
|
|
|
|
|
| |
Change-Id: Id4400b63f0bd5180194523f1efbac8b82c4dbe91
Reviewed-by: Pierre Rossi <pierre.rossi@gmail.com>
|
|
|
|
|
| |
Change-Id: Id7b35aab5012e1eba84fb3685b3bc6619aa92580
Reviewed-by: Pierre Rossi <pierre.rossi@gmail.com>
|
|
|
|
|
|
|
|
| |
For channels with multiple clients we used to create it once for
every client which is not needed.
Change-Id: Ib1be0c9f7bc78c0415fe2e9f6f8aa5112d0156c6
Reviewed-by: Pierre Rossi <pierre.rossi@gmail.com>
|
|
|
|
|
| |
Change-Id: I18a596c18530b18a833a58e734ce484caa6ae68f
Reviewed-by: Pierre Rossi <pierre.rossi@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
| |
In principle everything worked before already, with the difference
that responses to channel.exec could not properly be distinguished.
This is now fixed by adding a UUID to the WebChannel and sending that
along with the integer exec ID and comparing it in response messages.
Change-Id: I954716b04c1d9a41fffb8b9bb736a1fa45fec7f2
Reviewed-by: Pierre Rossi <pierre.rossi@gmail.com>
|
|
|
|
|
| |
Change-Id: I5948de7edff3aa8a58c9cc6e3789c4e7fffb7260
Reviewed-by: Pierre Rossi <pierre.rossi@gmail.com>
|
|
|
|
|
| |
Change-Id: I269ded913b25bb3d3869f2da85ce0ff7449b534b
Reviewed-by: Pierre Rossi <pierre.rossi@gmail.com>
|
|
|
|
|
| |
Change-Id: Id825cc0095398d72922700fa5c0d4f30cf19353c
Reviewed-by: Pierre Rossi <pierre.rossi@gmail.com>
|
|
|
|
|
|
|
|
| |
Enums that are marked by Q_ENUMS in a Q_OBJECT or Q_GADGET are thus
accessible in JavaScript via obj.EnumName.EnumKey.
Change-Id: Ia3e92da9bc05e06011f250ec8f5cf6ac26a3b0f4
Reviewed-by: Pierre Rossi <pierre.rossi@gmail.com>
|
|
|
|
|
| |
Change-Id: Idafda1326de072f9fa1853cb54cb0de459186bb1
Reviewed-by: Pierre Rossi <pierre.rossi@gmail.com>
|
|
|
|
|
| |
Change-Id: Ic0d9f536eee4e328fb4456fce7b84019dd7ff744
Reviewed-by: Pierre Rossi <pierre.rossi@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The code is much simpler in my opinion and much faster and far more
stable. Especially the timer issues or multiple signal connects
are now properly resolved.
Also simplify the QML WebChannel API:
- Rename slot to sendRawMessage and signal to rawMessageReceived
- Add a QML helper that has a respond and sendMessage method that
transforms the input to the expected JSON format.
Change-Id: Ic3266329d1a2877bd46227e4ad70b88dc340d289
Reviewed-by: Pierre Rossi <pierre.rossi@gmail.com>
|
|
|
|
|
| |
Change-Id: I7eeedea7666268a42db3c31c52255f12026e3fa3
Reviewed-by: Pierre Rossi <pierre.rossi@gmail.com>
|
|
|
|
|
| |
Change-Id: Iffc3278fd63620837fdc319bcebd4031a3901890
Reviewed-by: Pierre Rossi <pierre.rossi@gmail.com>
|
|
|
|
|
|
|
|
| |
This shows an issue with consecutive signal connections due to some error
in the socket communication. WebSockets should resolve this.
Change-Id: I091d70e5e7498abdcc449eeca8dfe171d1ce0287
Reviewed-by: Pierre Rossi <pierre.rossi@gmail.com>
|
|
|
|
|
| |
Change-Id: I52a3fc53ba0c76489ffdc0634cfaff5b1c1e02a4
Reviewed-by: Pierre Rossi <pierre.rossi@gmail.com>
|
|
|
|
|
| |
Change-Id: I4f4f101b40b3f509371819100ad70d2b2a5731f4
Reviewed-by: Pierre Rossi <pierre.rossi@gmail.com>
|
|
|
|
|
| |
Change-Id: I4bde0ed21e61009f7ac021b6539b2999e9fb14a8
Reviewed-by: Pierre Rossi <pierre.rossi@gmail.com>
|
|
|
|
|
|
|
| |
This can happen when one changes the webview URL e.g.
Change-Id: I24bf4b541e25d84c2e2698c9eaf4807141a775ee
Reviewed-by: Pierre Rossi <pierre.rossi@gmail.com>
|
|
|
|
|
|
|
|
|
| |
When multiple signals or properties exist we must not fall into
the usual javascript closure trap - we used to only use the very
last signal/property of every object...
Change-Id: Ief24630cc4b4ce3935207a170711f66c3ef5d805
Reviewed-by: Pierre Rossi <pierre.rossi@gmail.com>
|
|
|
|
|
|
|
|
| |
This makes it somewhat safer but is still error prone. I think we need
a proper WebSocket to make it really reliable.
Change-Id: I7a7f6305e026b3d75d906c948233a6bf210ed886
Reviewed-by: Pierre Rossi <pierre.rossi@gmail.com>
|
|
|
|
|
| |
Change-Id: I6ec18a1fd04d9b79f8bfbcb67bb49fc0959f54c5
Reviewed-by: Pierre Rossi <pierre.rossi@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Still, one can trigger XMLHttpRequest errors occasionally e.g.:
POST http://localhost:49158/6e933d76-843e-4b01-b273-fc36b0480ab1/POLL
Unknown error
This will then render the whole QObject bridge useless - I will
investigate.
Change-Id: Ifb7343414dac82e9af0a30ac008c3940283b1ecd
Reviewed-by: Pierre Rossi <pierre.rossi@gmail.com>
|
|
|
|
|
| |
Change-Id: Idc1fcbc4e68e68ace751caa41fa58bdffddc2890
Reviewed-by: Pierre Rossi <pierre.rossi@gmail.com>
|
|
|
|
|
|
|
|
|
| |
This is especially required for bigger response bodies,
as can happen now for multiple connections. Otherwise
the XHR will fail intermittently.
Change-Id: Iaac0fc6abda9e0e549acdda8f7e368d88ab17582
Reviewed-by: Pierre Rossi <pierre.rossi@gmail.com>
|
|
|
|
|
| |
Change-Id: I498660cac248fa94aa5a25b594f19f925a68adb6
Reviewed-by: Pierre Rossi <pierre.rossi@gmail.com>
|
|
|
|
|
| |
Change-Id: I108f10584d5cefbfef1ee9981eeb98c43b812391
Reviewed-by: Pierre Rossi <pierre.rossi@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This was especially noticeable when multiple timers where running.
In such cases only the very first signal would get submitted, then
the poll socket got closed. Consecutive calls to broadcast got lost.
Now we save the data passed to QWebChannel::broadcast and submit
it all in one go whenever a poll request comes in.
This fixes the timer issue and all signals get submitted. In the long
term this should all be properly rewritten using a WebSocket server
on the QML side and a WebSocket client on the HTML side.
Change-Id: I3b26f073978cf14b9bd045ec28b0279128c3c9e6
Reviewed-by: Pierre Rossi <pierre.rossi@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
We register objects once after the webchannel has initialized.
The web view URL on the other hand gets changed via property
binding after the web channel's base url is set/modified.
This hopefully fixes a race condition between the client-side HTML
logic and the registering of objects on the host-side QML app.
Change-Id: Ie83f7a415d9005e805a544f25287e51e75fb4dec
Reviewed-by: Pierre Rossi <pierre.rossi@gmail.com>
|
|
|
|
|
| |
Change-Id: Ic6c12fb6a51497129556b156483df59f8003c7a7
Reviewed-by: Pierre Rossi <pierre.rossi@gmail.com>
|
|
|
|
|
| |
Change-Id: Ic9e047d3c34749febc362710d486542b17150065
Reviewed-by: Pierre Rossi <pierre.rossi@gmail.com>
|
|
|
|
|
|
|
|
| |
Also move most of its implementation to C++ to reduce the context
switching.
Change-Id: I12d0284aa57d318eafe94d34e732796e522bcfd8
Reviewed-by: Pierre Rossi <pierre.rossi@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It might becme a very common use case of the QWebChannel QML plugin.
Thus it should be as simple as possible for third party consumers to
setup a QWebChannel for QObject publishing.
The new API basically moves the QtMetaObjectPublisher along with
the JavaScript marshalling to the qwebchannl/src folder.
The updated qtobject example shows how this new API can be used.
Furthermore note how it is now trivially possible to register
multiple objects, which was not easily possible before.
Some notes on the applied refactoring:
- qobject.js contains the JavaScript QObject binding and was
refactored to support multiple objects.
- the MetaObjectPublisher contains a new handleRequest function
which handles the QML-side of the QObject binding. This is
implemented in QML, while the other book keeping and esp. the
classInfoForObject is still handled in C++ via the
QtMetaObjectPublisher class (which is registered as
MetaObjectPublisherPrivate and used by MetaObjectPublisher)
Change-Id: Id45121bb654447e095bf8a8062d0c8edf9dcb018
Reviewed-by: Pierre Rossi <pierre.rossi@gmail.com>
|
|
|
|
|
|
|
| |
Mostly done by using QML (i.e. QtQuick2) instead of QtDeclarative.
Change-Id: I4d4f3d8c30bc10683fd7ad8c12e6198b0d848876
Reviewed-by: Pierre Rossi <pierre.rossi@gmail.com>
|
| |
|
| |
|
| |
|
| |
|