Hello Ciao,
Le 12/10/2011 01:26, Caio Marcelo de Oliveira Filho a écrit :
Hello Loïc,
Thanks for your questions and comments.
I see your examples and prototype code are always using a string as
message argument.
Is it possible to use a QVariant like with the QtWebKit bridge ?
I had in mind passing strings only. Users would handle serialization
(maybe thru libraries).
QVariant is not a good choice here IMHO because in the typical case
both sides will be talking JS already (at least one of the sides).
JSON.stringfy/parse, and the moral equivalent in Qt C++ would be
enough.
If I understand correctly, it won't be possible to implement synchronous
JS -> C++ calls like Q_INVOKABLE methods.
Message exchange would be asynchronous. We can support Q_INVOKABLE if
it's OK to get the answer in a callback, see below.
On Tue, Oct 11, 2011 at 7:32 PM, Loïc Yhuel
<[email protected]> wrote:
How would you wrap a QObject* (so it's signals could be invoked, properties
accessed) ?
On the WebView side, one could create a wrapper that take QObjects,
and post message warning the other side about the object being tracked
-- including properties and such. This watcher would send messages
when signals are emitted. On the other side (web page JS), when
information about new object is sent, a new object is created with
functions corresponding to slots and to property readings. Due to
asynchronous nature, we won't have the answers immediatly, so those
functions take callbacks. Essentially not very different from how IPC
works for WK2.
Note this is only one way to do it -- I'm not planning to support
QObject integration. But I think any asynchronous way to bridge the
things can be fit in the existing scheme.
Dynamically constructing wrapper functions, and sending them as JSON would
be complex, and probably slow.
I don't understand what do you mean by constructing wrapper functions
and send them as JSON. I don't think this is necessary.
You speak about sending object information to the web page JS, so it can
dynamically create a JS object.
My idea was similar, but with everything constructed on WebView side, so
the web page only has to evaluate what it receives to create an object
with property getters, wrapper functions sending messages to call
Q_INVOKABLE methods or emit signals on native side. But obviously your
solution is easier, as soon as we can use the WebScripts interface to
send the whole "object information parser" code in a js file.
Since there are two processes involved, one could try to do is to
optimize for the case of exposing QObjects as much as possible. My
proposal goes on the other direction: let's communicate in another
way.
In some cases, the best optimization would be to implement everything in
the web process.
You don't need the WebView if for example you want to expose D-Bus
services using QtDbus.
If synchronous calls are possible in this case, it will be even better,
as it would need less modifications to existing code.
Cheers,
_______________________________________________
webkit-qt mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-qt
