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

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)

anonyme_5308cee4763677866e1421efa4474f79

Il y a 9 ans

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.

yvan Abonné

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?

arno53

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 …

millman42 Abonné

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

Zyami Abonné

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.

Wapaca

ça pourrait aussi remplacer apache cordova à terme.

Anonyme_f7d8f7f164fgnbw67p

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)

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).
 
 

CryoGen Abonné

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 " />

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 " /> 

D’où cet article ;)

anonyme_751eb151a3e6ce065481d43bf0d18298

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.

" />

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à.

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 çà ?

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 " />

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

CryoGen a écrit :

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

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.

FRANCKYIV

ActionFighter :

Je vois que monsieur à remis son avatar … " />

brazomyna

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 ?

 
 

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

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 " />)

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.

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 " />)

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

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.
 
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.
 
 

 

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.

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.

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 ;)

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…).

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.

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.

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,  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.
 

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 " />

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

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

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

 Un jour peut-être tu comprendras à quel point JS bien utilisé est en fait “coolissime”, bien plus que Python " />

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

divide

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.

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 >= 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.

kestufou Abonné

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.

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

Impossible d'échapper au HTML5

Le nouveau Qt fait la part belle aux technologies du web

Support complet de WinRT et améliorations graphiques

Tiens, en parlant de ça :

#Flock a sa propre vision de l’inclusion

Retour à l’envoyeur

Quoi de neuf à la rédac’ #10 : nous contacter et résumé de la semaine

On est déjà à la V2 de Next ?

[Autoportrait] Sébastien Gavois : tribulations d’un pigiste devenu rédac’ chef

Me voilà à poil sur Internet

Sommaire de l'article

Introduction

Le nouveau Qt fait la part belle aux technologies du web

Support complet de WinRT et améliorations graphiques

#Flock a sa propre vision de l’inclusion

Quoi de neuf à la rédac’ #10 : nous contacter et résumé de la semaine

[Autoportrait] Sébastien Gavois : tribulations d’un pigiste devenu rédac’ chef

Pourquoi le site du média StreetPress a été momentanément inaccessible

re:Invent 2023 : Amazon lance son assistant Q et plusieurs services IA, dont la génération d’images

Le Conseil de l’UE tire un bilan du RGPD, les États membres réclament des « outils pratiques »

19 associations européennes de consommateurs portent plainte contre Meta

#LeBrief : Ariane 6 l’été prochain, Nextcloud rachète Roundcube, désinformation via la pub

CVSS 4.0 : dur, dur, d’être un expert !

Starlink accessible à Gaza sous contrôle de l’administration israélienne

G-PON, XGS-PON et 50G-PON : jusqu’à 50 Gb/s en fibre optique

Règlement sur la cyber-résilience : les instances européennes en passe de conclure un accord

AGI, GPAI, modèles de fondation… de quoi on parle ?

#LeBrief : logiciels libres scientifiques, fermeture de compte Google, « fabriquer » des femmes pour l’inclusion

Des chercheurs ont élaboré une technique d’extraction des données d’entrainement de ChatGPT

Devenir expert en sécurité informatique en 3 clics

ownCloud : faille béante dans les déploiements conteneurisés utilisant graphapi

Amazon re:invent : SoC Graviton4 (Arm), instance R8g et Trainium2 pour l’IA

Guéguerre des polices dans le cyber (OFAC et ComCyberMi)

#LeBrief : faille 0-day dans Chrome, smartphones à Hong Kong, 25 ans de la Dreamcast

OVHcloud Summit 2023 : SecNumCloud, IA et Local Zones

Transparence, discriminations : les questions soulevées par l’algorithme de la CAF

Plainte contre l’alternative paiement ou publicité comportementale de Meta

Économie de la donnée et services de cloud : l’Arcep renforce ses troupes

Plus de 60 % des demandes de suppression reçues par Google émanent de Russie

La Commission européenne et Google proposent deux bases de données de fact-checks

#LeBrief : des fichiers Google Drive disparaissent, FreeBSD 14, caméras camouflées, OnePlus 12

Commentaires (37)