Qt in the Cloud with QWebClient
Live Demo on hold! Try again later :)
(The demo itself is running on an Amazon EC2 instance. If you don't see a live demo here, try reloading the page. If it still doesn't work something has gone horribly wrong on the server or my credit card has maxed out.)
At this point I'd like to acknowledge the Wt project, which is a forerunner when it comes to C++-driven web applications. The difference between the two projects can be summarized by this table:
|Focus||Web Toolkit||Thin client for Qt apps|
|Quality||Stable code base||Greater Hack|
Adding thin client functionality to your application requires two lines of code for a simple one-user thin client. Supporting more than one user requires instantiating several copies if the user interface, which can be more complex depending on the application architecture. On the browser side the client code is equally simple, and if you request index.html from the server you will recieve the code.
|Qt Side (Server)||Browser Side (Client)|
(Notice "src=:qwebclient.js", the Qt resource system syntax has fond its way to the web!)
I'm targeting the use case where you have a server process running somewhere on a trusted network and want to expose a simple gui controlling it. This means:
- Simple, Form-like applications only, no animations or high-perforance graphics.
- Trusted networks only, there is little security. The implementation so far has been done with (eventual) security in mind though, so it's not hopeless.
- Limited scalability, support a few users only (check out http://126.96.36.199:1818/statistics to see how the live demo fares)
- It's a thin client, all program activity happens on the server (opening file and network connections, etc).
How Does It Work?
1. QWeblient starts a server at a user-configurable port
2. The Web Browser connects to the server and requests index.html. index.html loads qwebclient.js, which contains the thin client source code.
3.The Browser executes onLoad() which asyncronously requests /content from the server. The server replies with a json-encoded div element structure representing the widget hierachy. Common ui elemnts such as line edits are instantiated as native elements on the client side. All other widgets are transferred as images.
4.Keyboard and mouse events are POSTed to the server, which repsonds with content updates
5. When there are no client events, the browser will request /idle with one of its connections. The server will not reply to this request but keep the tcp connection open. (This the long-polling technique.)
6. Server events are sent to the client using the open long-polling connection.
This has been a fun project! Crossing over from the C++ world to the web world is interesting, you get to speak http using QTcpSocket on the server side and then debug result in FireBug on the client side.
Subscribe to our newsletter
Try Qt 6.6 Now!
Download the latest release here: www.qt.io/download.
Qt 6.6. is a feature release with focus on improving UX capabilities including responsive UI technology and the Qt Graph module.
Check out all our open positions here and follow us on Instagram to see what it's like to be #QtPeople.