Developpez.com - Rubrique Qt

Le Club des Développeurs et IT Pro

De nouveaux détails sur les plans pour Qt 6

Qui devrait contenir assez peu de nouvelles fonctionnalités par rapport à Qt 5.15

Le 2018-06-21 15:51:22, par dourouc05, Responsable Qt & Livres
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.
  Discussion forum
24 commentaires
  • LittleWhite
    Responsable 2D/3D/Jeux
    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.
  • koala01
    Expert éminent sénior
    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é
  • dourouc05
    Responsable Qt & Livres
    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.
  • Matthieu76
    Membre éclairé
    Envoyé par dourouc05
    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 ?
  • Matthieu76
    Membre éclairé
    Qt 6 ne sera pas basé sur C++ 2020 ? C'est vraiment dommage.
  • epsilon68
    Membre expérimenté
    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...
  • der§en
    Membre éprouvé
    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...
  • defZero
    Membre extrêmement actif
    @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 ).
  • epsilon68
    Membre expérimenté
    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.
  • Jbx 2.0b
    Membre chevronné
    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...