Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Discussion :

Qt 6 en 2020 ?


Sujet :

Qt

  1. #1
    Responsable Qt & Livres


    Avatar de dourouc05
    Homme Profil pro
    Ingénieur de recherche
    Inscrit en
    août 2008
    Messages
    24 684
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Ingénieur de recherche
    Secteur : Enseignement

    Informations forums :
    Inscription : août 2008
    Messages : 24 684
    Points : 166 226
    Points
    166 226
    Par défaut Qt 6 en 2020 ?
    Le Qt Contributors Summit s’est achevé cette semaine. La conférence rassemblait une centaine de contributeurs au projet Qt pour discuter de son avenir. L’un des principaux sujets de discussion a été la prochaine version majeure de Qt 6, la prochaine occasion pour casser la compatibilité du code existant et donc de revisiter certains choix de conception qui ne seraient plus adaptés au développement moderne (ce qui inclut également la liste des fonctionnalités désapprouvées lors de la vie de Qt 5).


    Le premier et principal changement prévu concerne la version de C++ : actuellement, seul C++11 est autorisé, tant pour développer Qt que dans son interface (aux débuts de Qt 5, c’était encore C++98…). Qt 6 se baserait exclusivement sur C++17 (puisque la norme C++20 ne serait probablement pas finalisée à temps).

    Qt 6 n’arrivera pas de sitôt : il faudra au moins attendre après Qt 5.14 (au moins dix-huit mois), c’est-à-dire en 2020.

    Les développeurs gardent en tête les problèmes de portage causés par le passé, afin de minimiser l’impact pour ceux qui devront mettre à jour leur version de Qt. Certaines API pourraient cependant changer pour devenir plus faciles d’utilisation — quitte à perdre légèrement en performance — : pour les utilisateurs, il est plus profitable d’avoir un outil facile à utiliser que plus performant, puisque les applications arriveront plus vite aux utilisateurs (et probablement avec moins de défauts).

    La compatibilité binaire sera aussi probablement cassée, afin de réduire la consommation de mémoire et d’implémenter certains algorithmes plus efficacement.

    Plus dans le détail, quelques modifications déjà prévues :

    • côté accessibilité : pour le moment, toute l’accessibilité (pour décrire l’interface de l’application à des outils comme des synthétiseurs vocaux) se base sur une copie de la hiérarchie des widgets et des composants. Cette manière de procéder est assez coûteuse en ressources et fragile (au moindre écart entre les hiérarchies, l’application peut planter). L’idée serait de fusionner l’interface d’accessibilité avec les widgets, de telle sorte que la hiérarchie ne soit plus dupliquée. Les données correspondant à l’accessibilité ne seraient allouées en mémoire que lorsqu’elles sont requises, ce qui reviendrait à une surcharge en mémoire d’un pointeur dans le cas de base ;

    • côté Qt WebEngine : le code entre l’implémentation à base de widgets et pour Qt Quick présente une certaine quantité de doublons, qui devrait être limitée. Le démarrage et l’arrêt du moteur Web sont actuellement décrits comme des hacks, leur implémentation devrait être améliorée. Plus important, l’API de QWebEnginePage devrait être retravaillée : il ne devrait pas être nécessaire de créer des classes dérivées aussi souvent. QWebEngineCallback devrait disparaître au profit de la bibliothèque standard : std::function. Toutes les classes pourraient finir dans un espace de noms QtWebEngine, au lieu d’avoir un préfixe à rallonge (QWebEngine) ;

    • côté Qt Widgets : certaines parties de l’API ont été placées dans Qt Widgets au lieu du module plus général Qt GUI avec la modularisation de Qt 5, mais leur place est probablement dans Qt GUI. Il s’agirait de QFileSystemModel (un modèle dont les données proviennent d’un système de fichiers) et des fonctionnalités d’annulation-restauration des actions. De même, la classe QSvgWidget aurait plus sa place dans le module Qt SVG ;

    • côté Qt UI Tools : ce module de chargement dynamique d’interfaces (similaire à Qt Designer) a toujours fonctionné comme une bibliothèque statique. Cependant, cette manière de procéder a un impact sur la licence : le module était sous licence BSD ou commerciale. Avec Qt 6, il devrait être possible de l’utiliser comme une bibliothèque partagée : il passera alors sous la même licence que le reste de Qt (LGPL ou commerciale) ;

    • côté style : le même code pourrait être utilisé pour les widgets et Qt Quick, à condition de retirer les dépendances trop fortes envers les widgets ;

    • côté Qt Quick : le moteur de rendu et le graphe de scène pourraient voir de grands changements arriver. L’objectif changera légèrement : le moteur actuel est orienté vers les applications 2D, mais s’ouvrira à l’intégration avec des moteurs 3D (comme Unity), de réalité virtuelle ou augmentée. Qt Quick servirait alors uniquement à la partie interface en 2D, avec l’affichage réalisé dans une texture réutilisée par une autre application. Les changements seraient assez profonds, mais simples : QQuickScene serait le point d’entrée, au lieu de QQuickWindow, qui ne serait dès lors plus nécessaire pour une application Qt Quick. Plus d’API de rendu seraient gérées : OpenGL et le rendu logiciel seront toujours gardés, mais complétés par Direct3D 12, Vulkan et d’autres.


    Voir aussi : la liste des changements déjà proposés pour Qt 6.
    Source : Qt Contributors’ Summit 2018 wrap-up.
    Vous souhaitez participer aux rubriques Qt ou PyQt (tutoriels, FAQ, traductions), HPC ? Contactez-moi par MP.

    Créer des applications graphiques en Python avec PyQt5
    Créer des applications avec Qt 5.

    Pas de question d'ordre technique par MP !

  2. #2
    Expert éminent sénior
    Avatar de koala01
    Homme Profil pro
    Consultant informatique
    Inscrit en
    octobre 2004
    Messages
    11 236
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 47
    Localisation : Belgique

    Informations professionnelles :
    Activité : Consultant informatique

    Informations forums :
    Inscription : octobre 2004
    Messages : 11 236
    Points : 27 810
    Points
    27 810
    Par défaut
    Salut,

    Il y a bien "longtemps" (c'était encore Qt-4.x ) j'avais proposé de rendre QMap plus "compatible" avec std::map, en rajoutant des paramètres template, parce que c'est template <Key, Value> QMap contre template <Key, Value, Comparator=less,Alloc = allocator<pair<const Key,T> >std::map.

    Cela avait été refusé à l'époque parce que cela aurait cassé la compatibilité binaire, ce que j'avais très bien compris. Mais Qt5 n'est sorti que plusieurs années plus tard, et, comme je n'y faisais pas trop attention à l'époque, je n'ai pas pu profiter de l'occasion pour relancer l'idée.

    Crois tu qu'il serait possible de la faire passer avec Qt-6
    A méditer: La solution la plus simple est toujours la moins compliquée
    Ce qui se conçoit bien s'énonce clairement, et les mots pour le dire vous viennent aisément. Nicolas Boileau
    Compiler Gcc sous windows avec MinGW
    Coder efficacement en C++ : dans les bacs le 17 février 2014
    mon tout nouveau blog

  3. #3
    Responsable Qt & Livres


    Avatar de dourouc05
    Homme Profil pro
    Ingénieur de recherche
    Inscrit en
    août 2008
    Messages
    24 684
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Ingénieur de recherche
    Secteur : Enseignement

    Informations forums :
    Inscription : août 2008
    Messages : 24 684
    Points : 166 226
    Points
    166 226
    Par défaut
    Très probablement, oui ! Tu profiterais aussi d'une ouverture plus directe aux nouvelles normes C++ et à la bibliothèque standard, ce qui était moins le cas avec Qt 5.
    Vous souhaitez participer aux rubriques Qt ou PyQt (tutoriels, FAQ, traductions), HPC ? Contactez-moi par MP.

    Créer des applications graphiques en Python avec PyQt5
    Créer des applications avec Qt 5.

    Pas de question d'ordre technique par MP !

  4. #4
    Membre éclairé Avatar de Matthieu76
    Homme Profil pro
    Consultant informatique
    Inscrit en
    mars 2013
    Messages
    564
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Consultant informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : mars 2013
    Messages : 564
    Points : 855
    Points
    855
    Par défaut
    J'utilise beaucoup Qt mais je n'utilise que des fonctions simples, à part un peu d'interface du multi-threading, je n'utilise pas grand-chose de Qt. L'interface de mes programmes est utilise Qt mais le back-end n'utilise pas du tout Qt, ne le référence même pas.
    À mon avis je ne verrais pas vraiment la différence entre QT 5 et Qt 6. Un QPushButton restera un QPushButton.

  5. #5
    Expert éminent sénior
    Avatar de koala01
    Homme Profil pro
    Consultant informatique
    Inscrit en
    octobre 2004
    Messages
    11 236
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 47
    Localisation : Belgique

    Informations professionnelles :
    Activité : Consultant informatique

    Informations forums :
    Inscription : octobre 2004
    Messages : 11 236
    Points : 27 810
    Points
    27 810
    Par défaut
    Citation Envoyé par dourouc05 Voir le message
    Très probablement, oui ! Tu profiterais aussi d'une ouverture plus directe aux nouvelles normes C++ et à la bibliothèque standard, ce qui était moins le cas avec Qt 5.
    J'ai donc introduit un rapport de bug pour lequel la réponse a été
    Current thinking is to reimplement QMap and QHash with Standard Library containers. I don't know if we need to define a comparator template parameter, but it doesn't hurt to
    J'ai fait valoir que, dans ce cas, rajouter un parametre template avec une valeur par défaut ne changerait pas grand chose pour l'implémenteur, mais pourrait changer énormément pour l'utilisateur

    Et les grands esprits se rencontrent, car, même si je ne l'ai pas proposé, je m'étais fait la réflexion que la bibliothèque standard avait bien évolué depuis les débuts de Qt, et que, s'il était cohérent de fournir différents conteneurs "perso" à l'époque, la SL a prouvé sa stabilité depuis, si bien que partir sur quelque chose comme
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    template <typename Key, typename Value, typename Comp=less>
    class QMap : private std::map<Key,Value,Comp>{
     
    };
    pour garder le nom du conteneur et pouvoir adapter les quelques fonctions qui divergent (en prenant / renvoyant un int au lieu d'un size_t) faciliterait la tâche
    A méditer: La solution la plus simple est toujours la moins compliquée
    Ce qui se conçoit bien s'énonce clairement, et les mots pour le dire vous viennent aisément. Nicolas Boileau
    Compiler Gcc sous windows avec MinGW
    Coder efficacement en C++ : dans les bacs le 17 février 2014
    mon tout nouveau blog

  6. #6
    Membre éclairé Avatar de Matthieu76
    Homme Profil pro
    Consultant informatique
    Inscrit en
    mars 2013
    Messages
    564
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Consultant informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : mars 2013
    Messages : 564
    Points : 855
    Points
    855
    Par défaut
    Citation Envoyé par koala01 Voir le message
    renvoyant un int au lieu d'un size_t
    Tiens d’ailleurs, pourquoi mon compilation me retourne un warning quand je compare un unsigned int à un size_t ?
    Un size_t n'est pas simplement un #define d'un unsigned int ? Un size_t est bien définie sur 4 octets ?

  7. #7
    Expert éminent
    Homme Profil pro
    Analyste/ Programmeur
    Inscrit en
    juillet 2013
    Messages
    2 985
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Analyste/ Programmeur

    Informations forums :
    Inscription : juillet 2013
    Messages : 2 985
    Points : 6 624
    Points
    6 624
    Par défaut
    Citation Envoyé par Matthieu76 Voir le message
    À mon avis je ne verrais pas vraiment la différence entre QT 5 et Qt 6. Un QPushButton restera un QPushButton.
    Et non Maintenant, on peut faire des connections/ signaux avec des fonctions anonymes.

    Et j'ai lu sur les Internets , que Qt veut remplacer le moteur graphique "QGraphicsView/ QGraphicScene" par du QML/ Qt Quick.
    Et là tu devras séparer la présentation (QML) du code logique (C++)


    Citation Envoyé par Matthieu76 Voir le message
    Un size_t n'est pas simplement un #define d'un unsigned int ?
    Et non Sur des plateformes 64 bits, un type int a une taille de soit 4 soit 8 octets.
    Et le type size_t doit avoir une taille de 8 octets [sur une plateforme 64 bits]*


    Édit : * rajout suite au message ci-dessous de koala01 et effectivement le verbe devoir est trop fort

  8. #8
    Expert éminent sénior
    Avatar de koala01
    Homme Profil pro
    Consultant informatique
    Inscrit en
    octobre 2004
    Messages
    11 236
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 47
    Localisation : Belgique

    Informations professionnelles :
    Activité : Consultant informatique

    Informations forums :
    Inscription : octobre 2004
    Messages : 11 236
    Points : 27 810
    Points
    27 810
    Par défaut
    Citation Envoyé par foetus Voir le message
    Et non Sur des plateformes 64 bits, un type int a une taille de soit 4 soit 8 octets.
    Et le type size_t doit avoir une taille de 8 octets.
    Il n'est mis nulle part qu'il doit avoir une taille de 8 octets...

    D'ailleurs, à part char <= short, short <= int, int <= long et long <= long long, et CHAR_BITS pour définir le nombre de bits d'un char, aucune taille n'est donnée pour les différents types

    Si tu veux travailler avec un type de taille précise, tu dois te tourner vers les alias de type intXX_t

    Ce qui est dit, c'est qu'il doit avoir un nombre de byte "suffisant que pour permettre la représentation de n'importe quelle taille sur le système cible".

    Ce doit être un type non signé, car une taille ne peut pas être négative, mais, selon le système cible (système d'exploitation, quantité de mémoire, ...), size_t peut être un alias de type sur unsigned short, unsigned int ou unsigned long long

    Du coup, l'avertissement peut varier en fonction de la situation (et des réglages du compilateur):

    S'il te parle simplement de comparaison entre une valeur signée et une valeur non signée, c'est que int et size_t font la même taille (mais l'un est signed et l'autre unsigned)
    s'il te parle de "perte de précision" ou de "perte de valeur", c'est que l'un est plus petit que l'autre
    A méditer: La solution la plus simple est toujours la moins compliquée
    Ce qui se conçoit bien s'énonce clairement, et les mots pour le dire vous viennent aisément. Nicolas Boileau
    Compiler Gcc sous windows avec MinGW
    Coder efficacement en C++ : dans les bacs le 17 février 2014
    mon tout nouveau blog

  9. #9
    Responsable Qt & Livres


    Avatar de dourouc05
    Homme Profil pro
    Ingénieur de recherche
    Inscrit en
    août 2008
    Messages
    24 684
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Ingénieur de recherche
    Secteur : Enseignement

    Informations forums :
    Inscription : août 2008
    Messages : 24 684
    Points : 166 226
    Points
    166 226
    Par défaut De nouveaux détails sur Qt 6
    Albert Astals Cid, un employé de KDAB (cette société étant l'une des plus grosses contributrices à Qt), donne sur son blog plus de détails sur les discussions qui ont eu lieu sur Qt 6. Tout d'abord, la date est bien confirmée pour novembre 2020. D'ici là, Qt 5 continuera à avoir ses versions mineures semestrielles, la dernière devant être Qt 5.15 (elle aura une maintenance à long terme).

    D'un point de vue technique, Qt 6 s'appuiera sur C++17, pas une norme plus ancienne. La migration devrait être très facile, au moins pour ceux qui ont suivi les fonctionnalités désapprouvées au fil du temps. En peu de mots, Qt 6 ne devrait pas avoir de fonctionnalité majeure, plutôt ressembler à Qt 5.15 en enlevant toutes les fonctionnalités désapprouvées et en changeant les interfaces qui doivent l'être. Pour faciliter la migration, l'essentiel des problèmes de compatibilité entre Qt 5 et 6 devraient être des choses qui cassent clairement à la compilation (sans nécessiter trop de travail de réécriture, de préférence) : autant que possible, les changements de comportement à l'exécution seront évités.

    Le système de compilation de Qt 6 n'est pas encore décidé, mais il est certain que ce ne sera plus qmake. Le choix semble assez limité, cependant : des gens travaillent sur Qbs (une petite étude a d'ailleurs été récemment lancée par le nouveau gestionnaire de produit), mais personne sur un autre candidat. CMake n'a pas été retenu, parce qu'il n'est pas compatible avec toutes les plateformes de Qt (pour l'embarqué, par exemple). Les fichiers de configuration nécessaires seront de toute façon inclus pour que l'on puisse compiler des applications Qt avec CMake.

    Ainsi, l'objectif est de continuer à travailler normalement sur Qt 5 : toutes les fonctionnalités qui peuvent y être intégrées le seront, elles ne seront pas retardées pour faire de Qt 6 une version particulièrement impressionnante.
    Vous souhaitez participer aux rubriques Qt ou PyQt (tutoriels, FAQ, traductions), HPC ? Contactez-moi par MP.

    Créer des applications graphiques en Python avec PyQt5
    Créer des applications avec Qt 5.

    Pas de question d'ordre technique par MP !

  10. #10
    Membre éclairé Avatar de Matthieu76
    Homme Profil pro
    Consultant informatique
    Inscrit en
    mars 2013
    Messages
    564
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Consultant informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : mars 2013
    Messages : 564
    Points : 855
    Points
    855
    Par défaut
    Citation Envoyé par dourouc05 Voir le message
    Le système de compilation de Qt 6 n'est pas encore décidé, mais il est certain que ce ne sera plus qmake.
    À mon avis je n'ai pas tout compris mais qmake ne fait pas que convertir les fichiers .pro en Makefile ? Et du coup, y aura-t-il aussi une nouvelle version de QtCreator ?

  11. #11
    Responsable 2D/3D/Jeux


    Avatar de LittleWhite
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    mai 2008
    Messages
    24 468
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : mai 2008
    Messages : 24 468
    Points : 180 092
    Points
    180 092
    Billets dans le blog
    50
    Par défaut
    Bonjour,

    Qt Creator est déjà compatible QBS.
    De plus, dire que qmake ne fait "que" convertir en Makefile, c'est un peu restreint. Premièrement, il ne génère pas que des Makefile (on peut générer des fichiers pour XCode, des fichiers pour Visual Studio...). Ensuite, il supporte un pseudo langage permettant les conditions, la création de fonction et bien plus.
    Vous souhaitez participer à la rubrique 2D/3D/Jeux ? Contactez-moi

    Ma page sur DVP
    Mon Portfolio

    Qui connaît l'erreur, connaît la solution.

  12. #12
    Expert éminent sénior
    Avatar de koala01
    Homme Profil pro
    Consultant informatique
    Inscrit en
    octobre 2004
    Messages
    11 236
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 47
    Localisation : Belgique

    Informations professionnelles :
    Activité : Consultant informatique

    Informations forums :
    Inscription : octobre 2004
    Messages : 11 236
    Points : 27 810
    Points
    27 810
    Par défaut
    En fait, qmake (et sans doute Qbs, que je ne connais absolument pas) est un outil de configuration de projet, au même titre que CMake ou les "autotools" (autoconf, autoheader, automake et libtool) sous linux.

    Il est un peu réducteur de parler de ces outils comme de "simple générateurs de Makefile", non seulement parce que, comme LittleWhite l'a fait valoir, il peut générer les informations permettant de compiler le projet pour différents EDI, mais surtout parce que cette génération n'est en définitive que la dernière étape d'un processus qui se contenterait de traduire
    j'ai tel fichier .cpp
    en langage "Makefile" sous la forme de
    compile x.cpp pour obtenir x.o
    ou
    j'ai <telle liste de fichiers .o>
    en langage Makefile sous la forme de
    génère moi la bibliothèque Truc.dll
    Avant cela, il y a tout un processus de vérification des dépendances et d'adaptations éventuelles qui doit être exécuté
    A méditer: La solution la plus simple est toujours la moins compliquée
    Ce qui se conçoit bien s'énonce clairement, et les mots pour le dire vous viennent aisément. Nicolas Boileau
    Compiler Gcc sous windows avec MinGW
    Coder efficacement en C++ : dans les bacs le 17 février 2014
    mon tout nouveau blog

  13. #13
    Responsable Qt & Livres


    Avatar de dourouc05
    Homme Profil pro
    Ingénieur de recherche
    Inscrit en
    août 2008
    Messages
    24 684
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Ingénieur de recherche
    Secteur : Enseignement

    Informations forums :
    Inscription : août 2008
    Messages : 24 684
    Points : 166 226
    Points
    166 226
    Par défaut Qt 6 commence à émerger sur Git
    Qt 6 n'est vraisemblablement pas prévu avant 2020. Il n'empêche que les développeurs commencent à s'activer pour cette version 6, avec des changements prévus qui s'accumulent — mais qui ne peuvent pas être intégrés dans Qt 5, à cause d'un problème de compatibilité binaire ou des sources. Par exemple, certains souhaitent ne plus laisser un accès direct aux données de QLabel par la méthode pixmap() : elle renvoie un pointeur sur les données internes de l'objet QLabel, alors qu'il serait possible de retourner directement les valeurs nécessaires (sans risque que le code extérieur manipule l'état du QLabel).
    Les plans au niveau du branchement dans le dépôt Git sont les suivants. Qt 6 disposerait de sa propre branche de développement, en parallèle de celle de Qt 5. Chacune aurait un développement actif et indépendant ; cependant, les changements apportés à Qt 5 seraient régulièrement fusionnés dans la branche Qt 6. Ceci ne serait valable que pour les modules développés dans le dépôt qtbase.git, pour des raisons liées au système d'intégration continue — bien évidemment, le travail continue de ce côté pour éliminer cette restriction.
    Pour limiter la casse lors de la mise à jour du code utilisateur vers Qt 6, les fonctions qui seront supprimées dans Qt 6 devront impérativement avoir été marquées comme désapprouvées dans une version de Qt 5. Aucun changement ne sera permis au niveau du système de compilation, sauf en ce qui concerne la migration complète vers CMake. Ce point est d'ailleurs bloquant pour le moment au niveau de l'intégration continue.
    Source : Qt 6 To Begin Early Stages Of Development In Git.
    Vous souhaitez participer aux rubriques Qt ou PyQt (tutoriels, FAQ, traductions), HPC ? Contactez-moi par MP.

    Créer des applications graphiques en Python avec PyQt5
    Créer des applications avec Qt 5.

    Pas de question d'ordre technique par MP !

  14. #14
    Membre éclairé Avatar de Matthieu76
    Homme Profil pro
    Consultant informatique
    Inscrit en
    mars 2013
    Messages
    564
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Consultant informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : mars 2013
    Messages : 564
    Points : 855
    Points
    855
    Par défaut
    Qt 6 ne sera pas basé sur C++ 2020 ? C'est vraiment dommage.

  15. #15
    Responsable Qt & Livres


    Avatar de dourouc05
    Homme Profil pro
    Ingénieur de recherche
    Inscrit en
    août 2008
    Messages
    24 684
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Ingénieur de recherche
    Secteur : Enseignement

    Informations forums :
    Inscription : août 2008
    Messages : 24 684
    Points : 166 226
    Points
    166 226
    Par défaut
    Qt vise aussi pas mal de plateformes embarquées, dont les compilateurs ont souvent du mal à suivre l'évolution de la norme C++… Il n'est d'ailleurs pas sûr que les compilateurs implémentent vraiment la norme C++2020 sans trop de défauts d'ici à Qt 6. Je trouve, au contraire, ce choix assez bien réfléchi — en espérant qu'ils se permettront de passer à une version plus récente de C++ dans le cycle de vie de Qt 6.
    Vous souhaitez participer aux rubriques Qt ou PyQt (tutoriels, FAQ, traductions), HPC ? Contactez-moi par MP.

    Créer des applications graphiques en Python avec PyQt5
    Créer des applications avec Qt 5.

    Pas de question d'ordre technique par MP !

  16. #16
    Responsable Qt & Livres


    Avatar de dourouc05
    Homme Profil pro
    Ingénieur de recherche
    Inscrit en
    août 2008
    Messages
    24 684
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Ingénieur de recherche
    Secteur : Enseignement

    Informations forums :
    Inscription : août 2008
    Messages : 24 684
    Points : 166 226
    Points
    166 226
    Par défaut Qt 6 : une vision technique proposée par Lars Knoll
    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…

    Qt Quick

    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.

    Infrastructure graphique

    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.

    Interfaces graphiques

    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.

    Outillage

    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.

    Langages

    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.

    Compatibilité ascendante

    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.
    Vous souhaitez participer aux rubriques Qt ou PyQt (tutoriels, FAQ, traductions), HPC ? Contactez-moi par MP.

    Créer des applications graphiques en Python avec PyQt5
    Créer des applications avec Qt 5.

    Pas de question d'ordre technique par MP !

Discussions similaires

  1. Réponses: 6
    Dernier message: 02/03/2011, 00h52
  2. Réponses: 34
    Dernier message: 31/07/2010, 15h53
  3. Réponses: 42
    Dernier message: 26/11/2009, 12h58
  4. GetCursorPos et lnk 2020
    Par christof63 dans le forum C++
    Réponses: 1
    Dernier message: 28/08/2008, 11h37

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo