IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Qt 6 : une vision technique proposée par Lars Knoll
C++17 au programme, Qt Quick pourrait se passer de JavaScript

Le , par dourouc05

251PARTAGES

18  0 
Qt 5 est sorti en 2012, déjà, il y a un peu moins de sept ans. L’énorme apport de cette version a été un fort découplage des fonctionnalités en modules bien plus indépendants qu’auparavant. Les widgets ont été déclassés, avec la séparation en Qt GUI (éléments absolument nécessaires pour l’intégration avec un système de fenêtrage) et Qt Widgets (les widgets classiques qui ont fait la renommée de Qt depuis ses débuts). La transition de Qt 4 à Qt 5 a pu se faire de manière assez simple (surtout en comparaison du passage de Qt 3 à Qt 4) : bon nombre d’API sont restées intactes, les fonctionnalités désapprouvées étaient signalées en amont avant leur suppression de Qt 5.

Qt 6 est attendu pour la fin 2020 (sauf retard, plus ou moins inéluctable quand on parle de Qt) et devrait poursuivre la même voie de Qt 5 : limiter les changements par rapport aux versions existantes, mais tout de même se préparer aux futures évolutions du framework et des besoins du marché. Une bonne partie des nouvelles fonctionnalités de Qt 6 sera disponible dans Qt 5.14 et 5.15, afin de faciliter la transition.

Qt 6 s’oriente vers les nouvelles utilisations de Qt. Les interfaces lourdes n’ont plus tellement la cote, mais elles ont permis à Qt de s’imposer, avec force animations et autres complexités (intégration d’éléments 2D et 3D, apparition de la réalité virtuelle et augmentée). Le matériel embarqué est la source de croissance la plus importante pour Qt : les utilisateurs veulent des interfaces intuitives, esthétiques, fonctionnant sur des écrans tactiles, sur du matériel (très) bon marché — heureusement qu’il ne faut pas y intégrer trop de fonctionnalités ! Sauf quand on parle d’intelligence artificielle…

[h=2]Qt Quick[/h]

Arrivé avec Qt 4 et peaufiné avec Qt 5, Qt Quick, l’environnement de création d’interfaces graphiques de manière déclarative, continuera à prendre une place importante dans Qt. Cet environnement est assez compliqué : les interfaces sont décrites en QML, l’interaction en JavaScript (du code inclus dans les fichiers QML ou externe) ou en C++, le moteur d’exécution est entièrement codé en C++… et il est même possible d’utiliser Qt Quick exclusivement en C++ ! Plusieurs changements d’envergure sont prévus, comme l’ajout d’un système de typage statique, afin de faciliter le travail d’utilitaires pour vérifier la correction du code, par exemple, mais aussi pour augmenter les possibilités d’optimisation du code.
En termes de performance, l’inclusion d’ECMAScript de manière forcée dans Qt Quick est parfois une limite, surtout sur des appareils très peu puissants — mais est extrêmement utile pour le prototypage d’une interface. JavaScript deviendra une composante optionnelle de Qt Quick, les interactions étant remplacées par du code C++. Aussi, le code QML deviendra compilable en C++ natif, notamment grâce au typage statique.

Tous les composants de Qt Quick disposent d’une version, ce qui facilite l’écriture d’une application qui dure dans le temps (on peut rester sur une version plus ancienne d’un composant à cause d’un changement de comportement ou d’interface dans une version plus récente). Cependant, le moteur d’exécution est rendu très compliqué à cause de cette possibilité de versionnage au niveau de QML : elle devrait disparaître (probablement aussi pour les extensions écrites en C++).

Qt Quick est prévu comme un environnement beaucoup plus dynamique que le code Qt en C++ habituel : bon nombre de structures de données sont générées au démarrage de l’application, ce qui prend un certain temps. Elles devraient être générées au moment de la compilation de l’application. De plus, ces structures sont parfois redondantes avec l’infrastructure QObject, ce qui génère des surcoûts en termes de temps de démarrage et de consommation de mémoire.

[h=2]Infrastructure graphique[/h]

Qt 5 révolutionnait déjà la manière d’afficher les interfaces graphiques, puisqu’une bonne partie du rendu était effectuée en OpenGL (quitte à livrer ANGLE, une implémentation d’OpenGL par-dessus DirectX, ce dernier étant généralement mieux géré sous Windows en l’absence de pilotes). Cependant, depuis ce choix, le monde de l’infographie 3D a beaucoup évolué : Vulkan est le successeur désigné d’OpenGL, Microsoft a lancé Direct3D 12 et Apple Metal (des API très similaires à Vulkan dans leurs principes, mais de bien plus bas niveau par rapport à OpenGL et les versions précédentes de Direct3D). Qt devra travailler de manière transparente avec toutes ces API de rendu pour bénéficier d’un maximum de performance sur le matériel actuel et futur — sans oublier que tout le matériel que Qt devra gérer ne sera pas forcément compatible avec ces dernières API.

Pour ce faire, il faudra une couche d’abstraction de l’API de rendu, tout comme QPA (Qt platform abstraction) fournit une couche d’abstraction de la plateforme sous-jacente (gestion des polices, des fenêtres, des curseurs, du presse-papiers, du thème, etc.). RHI (rendering hardware interface) remplira ce rôle : tout le code de rendu de QPainter, du graphe de scène derrière Qt Quick, de Qt 3D n’utilisera plus directement OpenGL, mais bien RHI.

RHI ne sera pas la seule solution en place : en effet, chaque API de rendu nécessite d’utiliser son propre langage pour écrire des nuanceurs, utilisés pour le rendu (GLSL pour OpenGL, HLSL pour Direct3D, SPIR-V pour Vulkan, MSL pour Metal — sans oublier les différentes versions de chacun de ces langages). Les développeurs de Qt ont en tête de développer le module Qt Shader Tools pour automatiser la transpilation des nuanceurs d’un langage à l’autre (juste avant l’exécution ou en amont).

Cette solution a été préférée à l’utilisation de bibliothèques de traduction, comme Zink (une implémentation d’OpenGL par-dessus Vulkan pour le pilote libre Mesa Gallium), MoltenGL (OpenGL par-dessus Metal) ou ANGLE. En effet, il s’agirait d’introduire d’énormes dépendances externes dans Qt (Zink est un pilote, MoltenGL un produit commercial). Toute dépendance externe nécessite un certain niveau de maintenance de la part des développeurs de Qt (ils en ont eu l’expérience avec ANGLE dans Qt 5).

Toujours dans l’infrastructure nécessaire au niveau graphique, il faudra un moyen de compresser les textures à envoyer au processeur graphique : celui-ci n’apprécie que moyennement des formats comme PNG, qui n’offrent pas un bon rapport entre la consommation de bande passante et le temps de décompression. Qt disposera de l’infrastructure nécessaire pour ce faire, au moment de la compilation de l’application, en fonction de la cible matérielle visée.

[h=2]Interfaces graphiques[/h]

La 3D dans Qt a pas mal évolué depuis Qt 5, notamment avec l’ajout du moteur 3D Qt 3D, mais aussi d’un environnement de développement d’interfaces graphiques entièrement 3D, Qt 3D Studio. Cependant, l’intégration de parties 3D dans une interface graphique n’est pas toujours naturelle ; il est actuellement impossible de synchroniser image par image deux animations, l’une 2D, l’autre 3D.

Pour ce faire, Qt Quick et QML évolueront : il n’y aura plus qu’un seul moteur de rendu, qui se chargera des parties 2D et 3D simultanément, peu importe le niveau d’imbrication des deux. QML deviendra le langage de déclaration des interfaces 3D, en remplacement d’UIP. Les développements en ce sens sont déjà bien avancés, puisqu’une première version de ce “Qt Quick 3.0” sera disponible avec Qt 5.14.

La gestion des styles entre les widgets et Qt Quick laisse franchement à désirer : Qt Quick n’a pas de notion de style de la plateforme, le développeur doit donc adapter ses composants pour qu’ils ne détonnent pas parmi d’autres applications au look vraiment natif. Bien sûr, une solution a été proposée : Qt Quick Controls, mais seulement la première version. La deuxième a abandonné le rendu proche du natif pour des raisons de performance. Pour les widgets, QPA se charge de faire le lien avec les composants natifs. Qt 6 apportera un moteur de style uniformisé, adapté tant aux applications lourdes qu’aux mobiles, utilisable tant par des widgets que Qt Quick.

[h=2]Outillage[/h]

De nouveaux outils pour le développement d’interfaces graphiques ont récemment fait leur apparition. Qt Designer facilite la conception d’interfaces à base de widgets (il est aussi intégré à Qt Creator). Pour Qt Quick, au début fut Qt Creator et son éditeur graphique ; ensuite, pour la 3D, on a eu Qt 3D Studio ; finalement, pour la 2D, Qt Design Studio. De quoi y perdre son latin, surtout que ces outils partagent certains morceaux de code — même s’ils sont dupliqués dans chaque projet. À terme, l’outil de conception d’interfaces graphiques Qt Quick sera Qt Design Studio, dont le code est déjà très proche de celui de Qt Creator. Il sera principalement prévu pour les concepteurs d’interface, plus ou moins sans code.

Côté développeur, PySide a refait son apparition il y a peu : on peut utiliser Qt en Python avec une interface officielle, avec une licence LGPL. Pourtant, Qt Creator rattrape lentement son retard pour le code Python. À terme, Qt Creator sera l’outil de choix pour les développeurs.

Un dernier sujet dans les outils a déjà fait couler beaucoup d’encre : l’abandon de qmake (et de Qbs, au passage) pour la gestion de la compilation des projets Qt. Qt 6 n’utilisera pas d’outil spécifique à Qt, mais bien CMake, l’outil le plus répandu dans le monde C++. Cela signifie que Qt ne sera plus compilé avec qmake, mais bien uniquement CMake. A priori, qmake pourrait rester distribué avec Qt 6 pour faciliter la transition des projets.

[h=2]Langages[/h]

Lorsque Qt 5 est sorti, le langage C++ était dans une phase de renouveau : C++11 venait de sortir, le comité s’était mis en tête de faire avancer le langage et sa bibliothèque standard plus rapidement. Les compilateurs n’avaient pas vraiment eu le temps de suivre : Qt 5 a dû se cantonner à C++03, par manque de compilateurs C++11 suffisamment stables depuis un certain temps pour toutes les plateformes. En effet, Qt ne peut pas se permettre d’obliger ses utilisateurs à utiliser les toutes dernières versions des compilateurs, pour des raisons de rétrocompatibilité.

Pour Qt 6, la situation a bien changé : entre temps, les normes C++14, C++17 et, très bientôt, C++20 sont sorties. On dispose de trois compilateurs majeurs qui respectent relativement bien les dernières nouveautés de la norme (GCC, Clang et Visual C++). Cela signifie que Qt 6 nécessitera au moins un compilateur C++17. Cela permettra d’utiliser les nouvelles constructions pour coder Qt, mais aussi de faciliter l’intégration avec la bibliothèque standard de C++.

Parmi les dernières API apportées à Qt, certaines ne sont utilisables qu’en QML, pas en C++. La raison principale est la flexibilité apportée par l’environnement d’exécution de Qt Quick par rapport à QObject : on peut lier des propriétés entre elles pour effectuer des mises à jour automatiques quand la valeur de la première change. Ce système est implémenté par les signaux et slots de Qt, mais est bien plus compliqué à mettre en œuvre en C++. Surtout, faire le lien entre Qt Quick et C++ impose une surcharge importante (occupation de mémoire, mais aussi en temps de calcul).

Ce point ne devrait pas être sous-évalué : QObject aura droit à de grandes évolutions avec Qt 6, avec un nouveau système de propriétés et l’implémentation des liaisons de Qt Quick. Cela facilitera l’interaction entre les deux univers, Qt Quick n’ayant plus grand-chose de particulier par rapport à QObject.

[h=2]Compatibilité ascendante[/h]

La compatibilité entre versions de Qt est un sujet important, tant au niveau des binaires que des sources : tout changement dans Qt peut casser des milliards de lignes de code écrites par ses utilisateurs. Aussi, si la migration est trop difficile, beaucoup d’utilisateurs préféreront rester sur Qt 5, qui devra être maintenu plus longtemps.

Par conséquent, le principe de base pour la transition entre Qt 5 et Qt 6 sera de préférer des erreurs nettes à la compilation, plutôt que des changements de comportement non explicités auprès de l’utilisateur, ces derniers étant bien plus difficiles à remarquer. La plupart des changements n’impliquera cependant qu’une incompatibilité binaire (il faudra recompiler les applications avec Qt 6, sans modifier le code source) : les ruptures de compatibilité des sources seront mineures, la plupart du nettoyage de code prévu pouvant se faire en cassant simplement la compatibilité binaire.

Certaines parties de Qt ont été désapprouvées avec le temps, étant remplacées par de nouvelles approches. Néanmoins, même si les widgets sont près de cette situation, ils resteront disponibles avec Qt 6 : ils sont trop utilisés pour que Qt puisse s’en passer. (Il n’est toutefois pas impossible que le système de widgets ait droit à un peu de modernisation, mais sans aucune certitude.)

Source : Technical vision for Qt 6.

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de epsilon68
Membre expérimenté https://www.developpez.com
Le 10/12/2020 à 0:22
je pense qu'ils m'ont perdu quand ils ont joué avec la licence...
d'un autre coté, .net core avance tres vite, bientot MAUI pour de l'UI multiplateforme,
donc je regarde encore Qt mais d'un seul oeil ... on sait jamais, mais plus le temps passe moins je regarde...
1  1 
Avatar de der§en
Membre éprouvé https://www.developpez.com
Le 10/12/2020 à 17:13
Moi, j'ai décroché, quand il fallait mettre du javascript pour faire les UI des programmes en C++.

Apparemment, ils sont en train de revenir au "full C++" et je ne dis pas que je ne vais pas y jeter un oeil...
0  0 
Avatar de defZero
Membre extrêmement actif https://www.developpez.com
Le 10/12/2020 à 19:07
@epsilon68, +1. En effet le coups sur le changement de licence leurs a quand même fait mauvaise presse, mais à côté de ça, il n'y a pas de véritable alternatives à part peut-être Delphi, donc l'équipe Qt peut bien se le permettre.

@der§en, Oui, enfin faire du Qt et faire du C++ sont 2 choses différentes.
Je rappellerais qu'entre C et C++ il n'y avait qu'un préprocesseur, alors venir qualifié Qt de "full C++", mouuuais c'est limite.
Quand à l'ajout de JS dans QtQuick, c'est quand même relativement plus facile et compréhensible de décrire ses UI avec des langages de plus au niveau, qui plus est sans avoir à gérer soit même les durées de vie de chaque objets, enfin je trouve personnellement mais ce n'est qu'un avis.

Pour ce qui est de Qt6, c'est une bonne chose qu'ils aient inclus des abstractions plus bas niveau et plus optimisé, mais ça a quand même était pas mal facilité par le fait que les API spécifiques aux plateformes ont de plus en plus tendance à converger dans leurs fonctionnement.
Par exemple pour la 3D, si RHI à été rendue possible, c'est bien parce que DX12, Metal et Vulkan ont bien simplifier la tache je pense (donc merci M$, Apple et Khronos ).
0  0 
Avatar de epsilon68
Membre expérimenté https://www.developpez.com
Le 11/12/2020 à 0:21
ben si il y a d'autres options que Qt:
- d'abord la licence est beaucoup trop chere
- sur desktop C# / WPF ou WinUI
- sur mobile React Native (js) ou Xamarin (C#) ou Flutter (dart)

Après, c'est un choix aussi valide de n'implementer une appli que sur 1 seule plateforme, par exemple C++ / objective C / swift sur ios / macos, ou de developper une couche C pour binder sur du C#

des solutions il y en a pleins en fait, et gratuites.

et rares sont les decideurs qui vont choisir C++, trop verbeux, dur et difficile à mettre en oeuvre.
0  0 
Avatar de Jbx 2.0b
Membre chevronné https://www.developpez.com
Le 11/12/2020 à 9:19
Pour ma part j'ai quand même l'impression qu'ils mettent Qt 3D sous le tapis pour promouvoir Qt Quick 3D. En effet la techno Qt 3D n'est plus disponible qu'en librairie additionnelle, pourquoi ? Et bien sur Qt Quick 3D, c'est GPL et commercial, donc ils ont tout intérêt à la mettre en avant.
Par contrer quand on choisit de monter un projet autour de Qt 3D en misant sur le LGPL, on a de quoi flipper...
0  0 
Avatar de archqt
Membre émérite https://www.developpez.com
Le 13/12/2020 à 14:28
- d'abord la licence est beaucoup trop chere
Exact très chère et à l'année, et tous les composants qui arrivent sont en licence Commercial ou GPL uniquement

- sur desktop C# / WPF ou WinUI
Pour linux, MacOS et Windows ou que sur Windows ? Après les performances C# sont quand même moins bonnes (je ne suis pas un spécialiste)

- sur mobile React Native (js) ou Xamarin (C#) ou Flutter (dart)
Oui mais il faut refaire le code

des solutions il y en a pleins en fait, et gratuites.
Oui mais, hélas, pas aussi abouties que Qt.


et rares sont les decideurs qui vont choisir C++, trop verbeux, dur et difficile à mettre en oeuvre.
Verbeux, pas sûr il faut juste utiliser une sous-couche du C++ (cela s'est bien amélioré par rapport au C++98). De plus avec les outils IHM (QtQuick) on peut faire des animations sans toucher au code de l'IHM. On implémente un "binding" IHM<->données en C++ et les 2 parties sont séparées.
Il n'y a pas, à ma connaissance (à part peut être FireMonkey de C++Builder) d'outils permettant de faire cela. Et bien évidemment les objets QtQuick permettant de faire cela sont sous licence commercial ou GPL.
Sous flutter il y a/avait une application qui permettait directement de faire le code de l'animation.
0  0 
Avatar de epsilon68
Membre expérimenté https://www.developpez.com
Le 13/12/2020 à 16:49
react native permet de faire ios et android et windows ... microsoft a meme sorti une version pour mac ...
flutter dart c'est pareil, c'est possible de faire une appli desktop (en preversion)
Xamarin MAUI c'est pareil

en fait c'est plutot Qt que je ne trouve pas abouti, ils ne resolvent pas les bugs, et point de vue rapidité, tu crois que QtQuick avec une VM javascript est rapide ?

bref, rien ne pourra justifier un tel prix, alors que des alternatives existent. Je mise beaucoup sur C# MAUI
0  0 
Avatar de archqt
Membre émérite https://www.developpez.com
Le 13/12/2020 à 18:15
Oui si on utilise du javascript cela ralenti, par contre le QML est compilé en C++ si l'on veut pour obtenir une pleine vitesse. Et personnellement je mets la logique de l'IHM en C++. Après on est d'accord c'est très très cher.
Les bugs il doit y en avoir comme partout je suppose.
Mais visiblement cela fonctionne dans l'automobile pour l'embarqué sinon ils ne mettraient pas un prix si élevé.

Ce qui est dommage c'est C++ Builder, vu "l'avance" qu'il avait sur les autres IDE dans les années 90 il aurait du être leader.
0  0