3 ms·

> Some time ago I published a couple of blog posts talking about Qt WebGL Streaming plugin I had to search to find out for sure what he was talking about. A Qt

> Some time ago I published a couple of blog posts talking about Qt WebGL Streaming plugin I had to search to find out for sure what he was talking about. A Qt application runs a small, local web server, streaming UI calls to a WebGL context on a page you view through your browser of choice. http://blog.qt.io/blog/2017/02/22/qt-quick-webgl-streaming/ http://blog.qt.io/blog/2017/02/22/qt-quick-webgl-streaming/ This differs from Electron in that your backend is C instead of JS, your UI is Qt instead of HTML, and the runtime doesn't embed the browser. I'm just guessing, but I suspect you also don't develop any code on the browser client context. I've also personally found value in running Electron from a page in a local HTTP server process, so I don't find that part too different, but YMMV. Maybe it's more appropriate to say this is like per-app RDP via WebGL.

d0lph 9y ago
Nitpick: C++ instead of C
WaltPurvis 9y ago
If I'm understanding you correctly, I don't believe that's the intended use for this technology. This is about streaming an application over the Internet, from a remote server, not from a localhost server. I can't think of any advantage to building a locally hosted Qt app that way. If you want to run a Quick/QML app locally, you just run it — there would be no gain and numerous penalties in running it through a web browser. (It also doesn't seem useful to compare it to Electron-based apps. The Qt comparison to an Electron app would be a Qt/QML app that uses Qt's WebEngineView, a control that embeds the Chromium browser.)
- moron4hire 9y ago
  That's a good point. I could also see this being useful on IoT devices to provide better UI fidelity for configuration tools across the LAN.
dom0 9y ago
Qt is commonly used for control UIs (also in industrial devices not running on a standard control system), so this would make remote control far easier to develop and deploy [1]. Essentially, yes, "per-app RDP". [1] It removes the need to develop a remote API/RPC interface, the need to make the app so modular that you can detach its UI completely, the need to built, test and distribute desktop releases etc.. It is also easier for the customers, "set password on device, put IP address in browser, done", and likely requires less support. It probably also works much better for use on tablets (which is becoming very common in many industries, well, at least where the work environments aren't too dirty); industrial control UIs have used touch input for a long time, and tend to use screens with sizes comparable to a tablet.

d0lph 9y ago

Nitpick: C++ instead of C

WaltPurvis 9y ago

If I'm understanding you correctly, I don't believe that's the intended use for this technology. This is about streaming an application over the Internet, from a remote server, not from a localhost server. I can't think of any advantage to building a locally hosted Qt app that way. If you want to run a Quick/QML app locally, you just run it — there would be no gain and numerous penalties in running it through a web browser. (It also doesn't seem useful to compare it to Electron-based apps. The Qt comparison to an Electron app would be a Qt/QML app that uses Qt's WebEngineView, a control that embeds the Chromium browser.)

moron4hire 9y ago
That's a good point. I could also see this being useful on IoT devices to provide better UI fidelity for configuration tools across the LAN.

dom0 9y ago

Qt is commonly used for control UIs (also in industrial devices not running on a standard control system), so this would make remote control far easier to develop and deploy [1]. Essentially, yes, "per-app RDP". [1] It removes the need to develop a remote API/RPC interface, the need to make the app so modular that you can detach its UI completely, the need to built, test and distribute desktop releases etc.. It is also easier for the customers, "set password on device, put IP address in browser, done", and likely requires less support. It probably also works much better for use on tablets (which is becoming very common in many industries, well, at least where the work environments aren't too dirty); industrial control UIs have used touch input for a long time, and tend to use screens with sizes comparable to a tablet.