why Qt haven't module to web app?
-
why Qt haven't module to web app?
-
Hi! Could you please elaborate on what exactly you mean?
-
Hi! Could you please elaborate on what exactly you mean?
@Wieland I mean if it has some module for web development like Java EE, Php and etc ...? But using Qt and Qml to development.
-
There is QmlWeb which claims to be "a QML engine in a web browser".
@Wieland but it's Qt Company?
-
Could be some interesting stuff coming in Qt 5.10! See: http://blog.qt.io/blog/2017/02/22/qt-roadmap-for-2017/ :
With Qt 5.10 we are planning to support streaming of Qt Quick application UIs over a network to a browser using WebGL. This streaming of OpenGL commands will allow using a common browser as a remote display of a Qt application running e.g. in a nearby embedded system or far across a network. Input from touch/mouse as well as keyboard is transmitted back to the Qt application. WebGL streaming will be implemented as a platform plugin in Qt 5.10. The streaming plugin converts all painting commands to WebGL commands and transmits the streams to clients. In turn those clients transmit user input back. Clients can be Qt applications or any web browser capable of showing WebGL 1.0.
Sounds very cool! Although bear in mind the real challenge with hoisting interactive apps into "the cloud" using simple remoting tech like RDP/VNC/AWS AppStream/TeamViewer/X11 etc etc is whether/how the app & protocol copes with increased latency and preserves responsiveness (or the illusion of responsiveness!). In my experience, while the "dumb" always-round-tripping remoting protocols work very well on LAN latencies and bandwidths, the experience over WAN latency is rarely satisfying. Web tech (done right) can be a big winner vs. protocols which need a round trip to the server for anything on the screen to change because web tech can embed a lot of immediate-response logic in the client with client-side JS... there's potentially that opportunity with QML+JS too, if something like clicking a button changing a state which changes a style could be kept entirely client-side, but from the description above it doesn't sound like this is doing that.
I think bandwidth and latency have been steadily improving though (despite many predictions of doom some years ago) so this approach's day may well come.
-
@Wieland but it's Qt Company?
@Everton-Fonseca As far as I can tell it's not related to the Qt Company. Don't know if that's a problem for you then, but it's been around for some time now, seems to be under active development and uses the MIT license. To me it looks good.
-
Could be some interesting stuff coming in Qt 5.10! See: http://blog.qt.io/blog/2017/02/22/qt-roadmap-for-2017/ :
With Qt 5.10 we are planning to support streaming of Qt Quick application UIs over a network to a browser using WebGL. This streaming of OpenGL commands will allow using a common browser as a remote display of a Qt application running e.g. in a nearby embedded system or far across a network. Input from touch/mouse as well as keyboard is transmitted back to the Qt application. WebGL streaming will be implemented as a platform plugin in Qt 5.10. The streaming plugin converts all painting commands to WebGL commands and transmits the streams to clients. In turn those clients transmit user input back. Clients can be Qt applications or any web browser capable of showing WebGL 1.0.
Sounds very cool! Although bear in mind the real challenge with hoisting interactive apps into "the cloud" using simple remoting tech like RDP/VNC/AWS AppStream/TeamViewer/X11 etc etc is whether/how the app & protocol copes with increased latency and preserves responsiveness (or the illusion of responsiveness!). In my experience, while the "dumb" always-round-tripping remoting protocols work very well on LAN latencies and bandwidths, the experience over WAN latency is rarely satisfying. Web tech (done right) can be a big winner vs. protocols which need a round trip to the server for anything on the screen to change because web tech can embed a lot of immediate-response logic in the client with client-side JS... there's potentially that opportunity with QML+JS too, if something like clicking a button changing a state which changes a style could be kept entirely client-side, but from the description above it doesn't sound like this is doing that.
I think bandwidth and latency have been steadily improving though (despite many predictions of doom some years ago) so this approach's day may well come.
@timday thanks my friend = D
