Connexion

Catégories

Droit Économie Flock Hardware IA Internet Logiciel Sciences Sécurité Société

Nous Suivre

Contact rédaction Contact site Forum
Flux RSS GitHub Discord

À propos

Abonnez-vous

Qt 5.4 améliore son support des technologies du web et de WinRT

Impossible d'échapper au HTML5

Qt 5.4 améliore son support des technologies du web et de WinRT

Le 11 décembre 2014 à 16h00

L’environnement de développement Qt vient de passer en version 5.4, avec à la clé un certain nombre d’améliorations en rapport avec les technologies du web. L’éditeur Digia en profite pour publier une mouture 3.3 de Qt Creator.

Le nouveau Qt fait la part belle aux technologies du web

Qt est un environnement de développement fournissant des API, des widgets ainsi que divers composants pour le réseau, le multimédia et ainsi de suite. Il permet aux développeurs de se baser sur ces éléments pour bâtir un projet qui pourra ensuite être compilé vers de nombreuses plateformes. Le client de virtualisation VirtualBox s’en sert ainsi pour simplifier son portage vers Windows, Linux, OS X et autres.

 

Dans son communiqué, Digia indique que le HTML5 et les technologies du web ont évolué et ont pris de l’ampleur, ce qui explique le travail réalisé sur ce domaine pour l’année écoulée. Aussi, l’une des plus grosses nouveautés de Qt 5.4 est l’arrivée de Qt WebEngine, qui servira donc de module responsable de l’affichage des ressources web. Il est basé sur le projet Chromium et utilise le moteur de rendu Blink de Google. L’API fournie permet donc d’intégrer du contenu web dans les applications à travers les Widgets et Qt Quick.

 

 

Autre apport important : Qt WebChannel. Il s’agit cette fois de créer un pont entre le duo QML/C++ habituel dans le développement des applications et le couple HTML/JavaScript. Ce qui permettra selon Digia de marier les technologies pour créer des applications hybrides. L’interface entre les deux univers sera réalisée par l’exposition des QObjects dans un contexte web. Par ailleurs, si le module fonctionne évidemment avec le nouveau Qt WebEngine, il pourra être utilisé avec n’importe quel moteur de rendu supportant les Web sockets, autrement dit tous les navigateurs récents.

 

La troisième nouvelle fonctionnalité web se nomme Qt WebView et n’est pour l’instant disponible que sous forme de préversion. Ce composant permet d’exploiter le navigateur fourni par la plateforme cible quand Qt WebEngine n’est pas entièrement requis. Pour l’instant, Qt WebView est compatible avec Android et iOS.

Support complet de WinRT et améliorations graphiques 

Mais le web n’est pas le seul domaine dans lequel Qt se renforce. Dans la version 5.3, le support du Windows Runtime (WinRT) était disponible en bêta. Il est désormais finalisé et les développeurs peuvent donc se servir de l’environnement pour créer des applications à destination du Windows Store de Windows 8.1. Les applications universelles sont également supportées, ce qui permet de viser également Windows Phone 8.1.

 

Parmi les autres nouveautés, signalons en particulier le support préliminaire des très hautes définitions d’écran. Les développeurs doivent le considérer comme expérimental, ce qui signifie qu’ils rencontreront des problèmes à son utilisation.

 

 

Côté graphique, Digia indique que le support d’OpenGL a souvent été problématique à cause de la mauvaise qualité des pilotes. Aussi, l’éditeur a ajouté un sélecteur qui permet de choisir dynamiquement l’implémentation OpenGL au démarrage d’une application, par exemple en sélectionnant l’OpenGL ES 2.0 d’ANGLE plutôt que le pilote natif. On notera également l’arrivée de deux nouveaux modules, QOpenGLWidget (remplaçant l’ancien QGLWidget de Qt 4) ainsi que QQuickRenderControl, qui permet de basculer le rendu de scènes Qt Quick dans un tampon.

 

Ceux qui souhaitent télécharger la nouvelle version de l’environnement ainsi qu’en savoir plus sur les nouveautés pourront se rendre sur la page officielle du produit. Notez que cette mouture s’accompagne de QtCreator 3.3, dont l’installation sera automatiquement proposée avec celle de Qt 5.4.

Commentaires (37)

Vous devez être abonné pour pouvoir commenter.

Abonnez-vous
votre avatar

Cool, les gens vont pouvoir introduire du contenu web avec tous les bugs de rendus de Blink, et dire que ce sont les autres navigateurs qui sont buggés quand c’est pas pareil que le rendu de Blink.

votre avatar

Ca va surtout permettre d’intégrer des web apps dans des applis “traditionnelles” non?



Enfin c’est ce que je comprends en tous cas.



Et si je comprend bien, ça ne peut qu’améliorer jolla niveau compatibilité avec le reste du monde/fonctionnalités et ça c’est très cool. non?

votre avatar

Sympa de voir que WinRT est de plus en plus supporter coté outils de développement. Entre ça et le support de DirectX12 du coté des moteurs de jeux comme l’Unreal Engine 4, les plateformes Windows 10 vont pouvoir tiré parti du travail réalisé pendant la phase transitoire qu’a été Windows 8 …

votre avatar

Avant Qt utilisait Webkit pour ces rendu Web cela ne change pas grand chose.

votre avatar

Je m’en sers avec Python (PyQT) et ce framework m’impressionne de plus en plus.

Moins pire que Django mais tout aussi productif, si en plus on peut l’intégration aux langages du web plus facilement…



Pas le temps.

votre avatar

ça pourrait aussi remplacer apache cordova à terme.

votre avatar







Zyami a écrit :



Je m’en sers avec Python (PyQT) et ce framework m’impressionne de plus en plus. 



Moins pire que Django mais tout aussi productif, si en plus on peut l'intégration aux langages du web plus facilement...




Pas le temps.





Ouah…. Ca veut dire quoi ton post, là ?

Tu t’en sers de Qt ou pas, finalement ? Comprends pas (sérieux)


votre avatar

Oui je m’en sers, juste que j’ai pas eu le temps de finir mon cpmm (ma mère et ma fille son arrivées en même temps) mais ce topic, ce framewoks je suis en plein dedans.

Je me suis fais mon exo qui va bien avec ces deux frameworls : Django et PyQT, PyQt s’intègre super bien avec l’OS, Django c’est plutôt sur serveur (AMPPS pour ma part en local).





Mon exo, c’est un simple carnet d’adresse en responsive; ça .l’air très con mais  cette appli englobe quasi tout ce que peut demander une appli web : BdD, CSS en responsive, le moins de JS possible, du coup plus de PHP mais  du Pyrhon.



Crois moi, personne ne paie des gens pour apprendre…



Si tu veus plus d’info, en MP (j’ai un wiki pour cela).

 

 

votre avatar

PyQt et Django ne conviennent pas pour le même besoin, ni la même finalité… les comparer c’est un peu étrange quand même <img data-src=" />

votre avatar







CryoGen a écrit :



PyQt et Django ne conviennent pas pour le même besoin, ni la même finalité… les comparer c’est un peu étrange quand même <img data-src=" />&nbsp;



D’où cet article ;)


votre avatar







yvan a écrit :



Ca va surtout permettre d’intégrer des web apps dans des applis “traditionnelles” non?

Enfin c’est ce que je comprends en tous cas.





<img data-src=" />



Qt WebEngine ne sert qu’à intégrer du contenu Web dans une appli Qt, pas à mettre un service en ligne accessible par les navigateurs mais qui utiliseraient le moteur blink, ça n’a pas de sens.



Qt WebChannel, par contre, permettra de mettre en place facilement un front-end en HTML/CSS (accessible par n’importe quel navigateur) et d’avoir un back-end en C++, chose qui n’était pas possible aussi simplement avant. Il fallait passer par des CGI générant l’HTML.







yvan a écrit :



Et si je comprend bien, ça ne peut qu’améliorer jolla niveau compatibilité avec le reste du monde/fonctionnalités et ça c’est très cool. non?





Ça peut améliorer Jolla dans son ensemble, vu que Sailfish OS est basé sur Qt, mais améliorer la compatibilité, je vois pas trop ce que tu veux dire par là.


votre avatar

Qt Webchannel n’est qu’une passerelle qui expose les object Qt mais pas un “framework css/js” pour créer des interface c’est bien çà ?

votre avatar







CryoGen a écrit :



Qt Webchannel n’est qu’une passerelle qui expose les object Qt mais pas un “framework css/js” pour créer des interface c’est bien çà ?





C’est ça <img data-src=" />


votre avatar

Merci, c’est bien ce que j’avais compris mais quelque part j’espérais me tromper <img data-src=" /> ca aurait été terrible d’avoir la plus part des widget-ui Qt pour créer des webapp via Qt Creator <img data-src=" />

votre avatar







CryoGen a écrit :



Merci, c’est bien ce que j’avais compris mais quelque part j’espérais me tromper <img data-src=" /> ca aurait été terrible d’avoir la plus part des widget-ui Qt pour créer des webapp via Qt Creator <img data-src=" />





Par contre, ça c’est possible apparemment avec Qt WebEngine, mais du coup, tu te retrouve avec un client lourd, là où l’intérêt ce serait d’avoir la même chose en client léger.



A voir ce que donne la suite de WebChannel, mais il y a du boulot, et quelque part, je trouve que la possibilité d’écrire l’UI uniquement en HTML/CSS/JS bien plus modulable que par des widget Qt.


votre avatar

ActionFighter :



Je vois que monsieur à remis son avatar … <img data-src=" />

votre avatar







ActionFighter a écrit :



Qt WebChannel, par contre, permettra de mettre en place facilement un front-end en HTML/CSS (accessible par n’importe quel navigateur) et d’avoir un back-end en C++, chose qui n’était pas possible aussi simplement avant. Il fallait passer par des CGI générant l’HTML.





J’avoue que je ne saisis pas l’intérêt du truc (vraie question)



A priori, si demain je veux faire une solution où le front end s’exécute dans n’importe quel navigateur, on fait un frontend classique via les nombreux frameworks HTML qui existent (genre Angular pour une webapp) et on expose les interactions avec un service/démon en backend via une API bien délimitée et standard (genre du JSON / REST).



Sinon, si je veux intégrer une vue HTML dans une appli Qt (fusse l’ensemble du front-end), le QtWebEngine semble tout approprié.



Quel est l’intérêt de Qt WebChannel alors ?



&nbsp;

&nbsp;


votre avatar

C’est une usine à gaz ce framework mais ça permet tout.. sur python depuis wx… euh comment dire… Une usine à gaz.

votre avatar

Bah c’est justement pour mettre en place ton API directement via Qt plutôt que d’ajouter un autre tiers dans la chaine (si j’ai bien tout compris <img data-src=" />)

votre avatar







brazomyna a écrit :



J’avoue que je ne saisis pas l’intérêt du truc (vraie question)



A priori, si demain je veux faire une solution où le front end s’exécute dans n’importe quel navigateur, on fait un frontend classique via les nombreux frameworks HTML qui existent (genre Angular pour une webapp) et on expose les interactions avec un service/démon en backend via une API bien délimitée et standard (genre du JSON / REST).





Le but de WebChannel est de pouvoir faire ça de manière très simple, avec du HTML/CSS/JS, sans recourir à un framework/API spécifique qui ajoute des dépendances.



Le WebEngine, comme tu l’as dit, sert lui à intégrer une vue HTML dans une appli.



Les deux ont donc une fonction bien différente.


votre avatar







CryoGen a écrit :



Bah c’est justement pour mettre en place ton API directement via Qt plutôt que d’ajouter un autre tiers dans la chaine (si j’ai bien tout compris <img data-src=" />)





Ca veut dire aussi ne bosser que pour un framewoks, tu te rends compte de la bêtise que tu dis ?


votre avatar







ActionFighter a écrit :



Le but de WebChannel est de pouvoir faire ça de manière très simple, avec du HTML/CSS/JS, sans recourir à un framework/API spécifique qui ajoute des dépendances.





On ne parle pas de dépendances, on parle de communication entre deux entités au moyen d’un standard (Le protocole HTTP et le JSON) ultra répandu, et déjà dispo dans le navigateur, comme dans Qt.

&nbsp;

Ce qui ne me semble pas optimum du tout c’est de coupler fortement son front-end avec son back-end avec une techno qui est tout sauf standard et réutilisable.



Si demain mon besoin évolue et que je veux non plus aller chercher mes infos publiées par mon démon Qt via un navigateur, mais via un front-end codé en Java ou en Cobol, je suis baisé à moins de me taper une ré-implémentation complète de leur protocole WebChannel obscur, ou d’attendre que Digia en fasse un portage sur la techno qui m’intéresse.

&nbsp;

&nbsp;



&nbsp;


votre avatar







Zyami a écrit :



Ca veut dire aussi ne bosser que pour un framewoks, tu te rends compte de la bêtise que tu dis ?







Gné ?



J’ai dis qu’il fallait absolument bosser avec Qt moi ? non je ne crois pas alors descend de tes grands chevaux.

Un commentaire demande l’intérêt de Qt Webchannel, j’ai répondu, point.



Maintenant si quelqu’un veut mixer des framework, ne pas en utiliser du tout ou n’en utiliser qu’un seul, c’est son choix… pas le mien ni le tien.



Alors non je n’ai pas dit de bêtise.





votre avatar







CryoGen a écrit :



Alors non je n’ai pas dit de bêtise.






Effectivement, c'est pas une bétise, et pour une solution qu'on veut entièrement basée sur Qt, c'est un moyen de simplifier (un peu, hein) l'interfaçage entre le back et le front (et encore, il faudrait voir à quel point la gestion des autorisations d'accès et de sécurité ne sont pas limitantes en soi).      







Mais il est bien connu qu'un projet a des besoins à un moment X qui évoluent au fur et à mesure du temps qui passe. Et le petit gain en terme de facilité de codage du départ me semble tout de même très ténu par rapport au risque de se retrouver coincé le jour où on veut évoluer.

votre avatar







CryoGen a écrit :



Gné ?



J’ai dis qu’il fallait absolument bosser avec Qt moi ? non je ne crois pas alors descend de tes grands chevaux.

Un commentaire demande l’intérêt de Qt Webchannel, j’ai répondu, point.



Maintenant si quelqu’un veut mixer des framework, ne pas en utiliser du tout ou n’en utiliser qu’un seul, c’est son choix… pas le mien ni le tien.



Alors non je n’ai pas dit de bêtise.





Merki ;)


votre avatar







ActionFighter a écrit :



Le but de WebChannel est de pouvoir faire ça de manière très simple, avec du HTML/CSS/JS, sans recourir à un framework/API spécifique qui ajoute des dépendances.



Le WebEngine, comme tu l’as dit, sert lui à intégrer une vue HTML dans une appli.



Les deux ont donc une fonction bien différente.





La seule différence que je vois, c’est l’intégration de python avec cela. Un modèle, une vue un render de template.



Pour ceux qui auraient besoin d’un tel frameworks ,un mois de salaire, c’est le prix d’un 20 m2 à Saint Etienne..(2 mois de salaire à tout casser, et je parle dachat…).


votre avatar







brazomyna a écrit :



On ne parle pas de dépendances, on parle de communication entre deux entités au moyen d’un standard (Le protocole HTTP et le JSON) ultra répandu, et déjà dispo dans le navigateur, comme dans Qt.





Je parlai dans le cas d’un back-end qui s’appuierait sur Qt, le but de WebChannel étant de simplifier l’interaction dans ce cas.

 





brazomyna a écrit :



Ce qui ne me semble pas optimum du tout c’est de coupler fortement son front-end avec son back-end avec une techno qui est tout sauf standard et réutilisable.





Je relativiserai le “fortement”. Si le code est bien construit, le changement se fait tout de même assez facilement.



L’intérêt étant surtout de pouvoir développer rapidement un front-end HTML, ce qui peut avoir son intérêt pour des appli Qt client-serveur avec un client lourd, ou des applis avec un front-end qml initialement destinée à android ou jolla, pour les rendre accessible par navigateur.



Ce n’est pas une solution miracle, je suis d’accord. Si tu veux un back-end et des front-end pleinement interopérables, il est préférable de rester sur des technos standards.







brazomyna a écrit :



Si demain mon besoin évolue et que je veux non plus aller chercher mes infos publiées par mon démon Qt via un navigateur, mais via un front-end codé en Java ou en Cobol, je suis baisé à moins de me taper une ré-implémentation complète de leur protocole WebChannel obscur, ou d’attendre que Digia en fasse un portage sur la techno qui m’intéresse.





Dans ce cas, il est clair que WebChannel ne conviendra pas, mais là, même le choix d’un démon Qt est pour moi à revoir.



Qt, c’est très bien pour faire des interfaces graphiques portables, mais en mode client-serveur, si qml n’est pas utilisé en client, il n’y a pas d’intérêt à se trimbaler une usine à gaz comme qt en back-end.







Zyami a écrit :



Pour ceux qui auraient besoin d’un tel frameworks ,un mois de salaire, c’est le prix d’un 20 m2 à Saint Etienne..(2 mois de salaire à tout casser, et je parle dachat…).





Qt est aussi dispo en open-source.


votre avatar

Je reformule le premier point, qui n’est pas très clair à la relecture :



Le but de WebChannel est de pouvoir expose les interactions de manière très simple un back-end qt, avec du HTML/CSS/JS, sans recourir à un framework/API spécifique qui ajoute des dépendances. et sans avoir à gérer la sérialisation.

votre avatar







ActionFighter a écrit :



Je reformule le premier point, qui n’est pas très clair à la relecture :



Le but de WebChannel est de pouvoir expose les interactions de manière très simple un back-end qt, avec du HTML/CSS/JS, sans recourir à un framework/API spécifique qui ajoute des dépendances. et sans avoir à gérer la sérialisation.





Ca ne remplacera jamais le JS, mais avoues,&nbsp; si on peut s’en passer on est tous prêt à foncer dedans, même si ça ne sert à rien. Le push ne va pas se faire tout seul en attendant, pour l’instant Python et persoonne n’arrive à faire un truc coolissime.



Ayez, je me lance dans les tests unitaires, youhou.

&nbsp;


votre avatar







Zyami a écrit :



Ca ne remplacera jamais le JS, mais avoues,  si on peut s’en passer on est tous prêt à foncer dedans, même si ça ne sert à rien. Le push ne va pas se faire tout seul en attendant, pour l’instant Python et persoonne n’arrive à faire un truc coolissime.



Ayez, je me lance dans les tests unitaires, youhou.





Non, on est pas près de se passer de JS, puisque WebChannel l’utilise <img data-src=" />


votre avatar







Zyami a écrit :



Le push ne va pas se faire tout seul en attendant







Un petit tour dans la doc plus tard, Qt Web Channel fait au contraire tout seul du push des updates des objets exposés:





property updates and signal emission on the C++ side get automatically

transmitted to the potentially remotely running HTML clients. On



source



&nbsp;Son intérêt, c’est peut-être surtout celui-là plus que l’espèce de couche de sérialisation “proprio”


votre avatar



Ca ne remplacera jamais le JS, mais avoues,&nbsp; si on peut s’en passer on est tous prêt à foncer dedans



&nbsp;Un jour peut-être tu comprendras à quel point JS bien utilisé est en fait “coolissime”, bien plus que Python <img data-src=" />

votre avatar

Oui parce qu’on a pas d’autres choix, c’est la seule et unique raison.

votre avatar

J’ai porté mon appli sur Qt 5.4 et pour moi qui ne suit pas du tout orienté web, les gains sont tout aussi conséquents : le nouveau QOpenGLWidget est super pratique/fluide comparés aux modules précédents, et le support High-DPI sous Windows en plus d’OSX est tout aussi bienvenu.

J’utilise ce framework depuis 2009 (Qt 4.6) et je ne cesse d’être émerveillé par chaque nouvelle version. C’est en train de devenir le framework multi-plateforme/multi-usage ultime pour toute application qui nécessite performance et accès bas niveau.

Pour rappel, il va d’ailleurs bien plus loin que la gestion d’interface, c’est un ensemble de classes qui simplifie et accélère le développement a à peu près tous les niveaux.

votre avatar

Ancien utilisateur de Qt (j’ai dû commencer en 3.0 ou 3.5), c’est vrai que ce framework C++ a toujours eu un gros à-priori positif chez moi. D’autant plus depuis que l’ensemble est devenu modulaire (Qt &gt;= 4.0 si mes souvenirs sont bons).



Reste le langage sous jacent, le C++, qui a fini par m’éloigner de ce genre de solution. C’est un très bon langage dans l’absolu et ça restera mon “premier amour” côté OOP, mais c’est vraiment peu productif à l’écriture, je trouve.



ça n’engage évidemment que moi, mais amha hormis pour 1% des cas où on a vraiment besoin de tirer la quintessence de perfs d’un ordi, plus les choses avancent, plus je privilégie du langage plus ‘haut niveau’ plus productif à coder. A ce titre, Node et le JS font des merveilles. C’est un langage très permissif et donc dangereux pour un débutant ou un codeur pas très ‘carré’, mais pour qui a un bon passif par exemple en c, c++ et de la rigueur, c’est ultra productif et souple.

votre avatar

Nous sommes deux alors.

J’ai commencé avec Qt 4.3 pour une appli avec ce que qui est maintenant dans le module Widgets.

Depuis 2 ans, je fais une appli C++/QML. En parallèle, je me suis amusé à faire les adaptations necessaires iOS et Android, ça marche plutôt pas mal.

Cependant, ça fait quelques temps que je réfléchis à comment je pourrais me dispenser de ces applis iOS, Android, Desktop pour faire un truc uniquement web-based.

votre avatar

Je pensais à pouvoir intégrer facilement de la cartographie ou du cloud (images etc.) dans des applis natives, des choses comme ça.



Après je n’ai pas (encore, je me tâte à switcher) de tel sailfish donc je ne peux détailler plus ce que j’en attendrais concrêtement mais le côté petit écosystème marginal implique forcément des lacunes dans l’intégration des services disponibles a priori, notamment tout ce que font google/apple/ms avec la cartographie, la recherche etc.

Qt 5.4 améliore son support des technologies du web et de WinRT

  • Le nouveau Qt fait la part belle aux technologies du web

  • Support complet de WinRT et améliorations graphiques 

Fermer