I've been playing with javascript lately, and here's the result: QWebClient, a thin client for Qt applications. This is a pure Javascript implementation which runs in any modern browser (no plugins required). QWebClient works by starting an http server in the application process, which the browser then connects to. The project currently has research quality - get the source at qt.gitorious.org
Live Demo on hold! Try again later :)
View Source
(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.)
Prior Art
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:
| Wt | QWebClient | |
| Focus | Web Toolkit | Thin client for Qt apps |
| Quality | Stable code base | Greater Hack |
User Code
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) |
|
<html><head> <script type="text/javascript" src=":qwebclient.js" mce_src=":qwebclient.js"></script> </head> <body> </html> |
(Notice "src=:qwebclient.js", the Qt resource system syntax has fond its way to the web!)
Scope
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://79.125.3.129: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.
Obligatory Conclusion
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.
