Bon nombre d’utilisateurs de Qt aimeraient rendre leur interface utilisable depuis une autre machine, par exemple à travers Internet comme une application Web. Cependant, par conception, ce n’est pas une chose que Qt peut faire facilement : les communications ne se passent pas par un protocole comme HTTP ou sockets Web entre le cœur de l’application et son interface, mais plutôt à l’aide de signaux et de slots.Néanmoins, on peut arriver à utiliser WebGL pour transmettre les commandes d’affichage à un navigateur, donc à afficher son application à l’intérieur d’un navigateur sans devoir trop coder en HTML ou JavaScript — et sans devoir rien installer sur le poste client. Si l’application est correctement découplée entre un cœur et un affichage (idéalement développé avec Qt Quick), la transformation sera relativement aisée. En effet, Qt dispose d’une extension de plateforme qui fonctionne sous la forme d’un serveur WebGL : la communication se passe par sockets Web, l’application Qt envoyant des commandes WebGL à afficher.
Pour les applications à base de widgets, cette technique ne fonctionne pas, il vaut mieux alors se tourner vers l’implémentation des protocoles VNC (une implémentation est disponible depuis Qt 5.8). La performance sera nettement moins bonne, puisque la communication se fait à l’aide d’images plutôt que de commandes d’affichage.
Ces deux approches fonctionnent très bien pour peu de clients : pour un grand nombre, par contre, vu qu’un même serveur doit se charger d’afficher l’application (directement ou “juste” générer les commandes d’affichage), ces mécanismes ne fonctionnent plus (par exemple, dans le cas de SaaS). Une autre manière de fonctionner exploite plutôt WebAssembly : dans ce cas, l’application tourne directement dans le navigateur côté client. Au lieu de la compiler pour qu’elle fonctionne sur un serveur, elle est transformée en fichiers WASM (du code binaire WebAssembly). La communication se fait alors à l’aide de canaux séparés, dans des requêtes HTTP ou sockets Web — exactement comme si l’application était exécutée nativement, hors de tout navigateur.
La technique exploite Emscripten pour compiler Qt au complet en WebAssembly, avec cependant quelques limitations. En effet, une application WebAssembly dans un navigateur ne peut pas faire n’importe quoi, pour des raisons de sécurité. Par exemple, il n’est pas possible d’utiliser des fils d’exécution. Les applications ainsi générées sont relativement rapides, bien que pas toujours très légères. Qt Quick est également de la partie.
Source : Remote UIs with WebGL and WebAssembly, Qt for WebAssembly.
Et vous ?
Qu'en pensez-vous ?