[Development] Future of QWebChannel

[Milian Wolff]

Hey all!

For those of you who haven't heard of QWebChannel, take a look at [1]. It is a 
bridge between QML/QtQuick 2 and the web. It uses MetaObject introspection and 
IPC to publish QObjects to HTML/JavaScript and make them accessible there.

The project was originally spearheaded by Noam, many thanks for that again!
Due to lack of time the "official" code in the qt-labs repository stagnated 
and is more or less a proof-of-concept demo only. KDAB had demand for this 
technology to be used in a productive environment. Thus our "fork" [2] was 
born, which we internally now refer to as "upstream" :)

Compared to the initial proof-of-concept in the offical qt-labs repository, 
the fork comes with quite a few bug fixes, added functionality (such as 
wrapping QObjects on the fly, to support factory-like functions e.g.), and 
tons of performance improvements (we use WebSockets now, cache properties on 
the HTML side and try to minimize the JSON traffic).

Today, I made sure that all our internal changes are available on gitorious 
[2]. This now can be used as a ground for discussion.

We would like to integrate our changes into the official qt-labs repository. 
Could this be done somehow? I.e. would someone accept a merge request on 
gitorious, or how can we proceed here? Ignoring QtWebEngine for now (see 
below), the QWebChannel fills the gap of a QML/C++<->HTML/JavaScript for 
QtWebKit-based hybrid applications. Since QtWebKit will stay around until Qt 
6, people should be able to find the improved QWebChannel at an official 
place. Besides QtWebKit, the QWebChannel would also (with minor changes) allow 
a transparent dialog between any kind of semi-modern HTML browser (even 
remote) and a QtQuick2/C++ server.

I would welcome any contributions and feedback, and do plan to maintain the 
QWebChannel code in the future.

That being said, I'm looking forward to the future that is QtWebEngine. We 
will investigate how to integrate a similar QObject bridge there directly, 
which should give higher performance and reduce the boiler plate code required 
to setup the bridge. The existing QWebChannel code gives us a lot of insight 
in what is required from a usage POV and also shows what could and should be 
improved. I would welcome if people interested in the topic take a look at the 
code and the examples.

Bye

[1]: https://qt.gitorious.org/qt-labs/qwebchannel/source/d1eeac733c47e106af2aeb34cf24beb36a1c60fe:README
[2]: https://qt.gitorious.org/qt-labs/milianws-qwebchannel/
-- 
Milian Wolff | milian.wolff at kdab.com | 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