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 !

QtCon, première journée
Nouveautés pour macOS, analyse des performances et futur de Qt, un compte-rendu d'Arnold Dumas

Le , par arnolddumas

0PARTAGES

6  0 
La QtCon se déroule au Berlin Congress Center à Berlin et remplace en quelque sorte les Qt Developer Days, tout en fédérant d'autres communautés comme VLC, FSFE ou encore KDE. Les sessions sont pour la plupart techniques et touchent à différents aspects de Qt, de son développement à son utilisation. J'ai pour ma part assisté à quelques conférences, pour lesquelles je vous propose un compte-rendu.

« Qt on OS X » par Morten Sørvig

Une présentation qui se trouvait en fait être une sorte d'atelier où différents employés de la Qt Company étaient présents. Différents aspects relatifs à macOS y sont discutés.

Samuel Gaist a proposé deux séries de patchs sur Gerrit, afin d’implémenter un système de notification sous macOS. Cela pourrait devenir un module à part entière si d’autres systèmes d’exploitation venaient à être supportés.

Le 32 bits devrait être abandonné. Le seul cas pour lequel le 32 bits est encore nécessaire est lorsqu'il faut lier à des bibliothèques non disponibles en 64 bits.

Une nouvelle API est disponible sous macOS >= 10.9. Celle-ci devrait permettre d’améliorer l'espace et l’alignement entre les composants de l'interface graphique. Typiquement, toutes les valeurs actuellement en dur dans le code pour macOS devraient pouvoir être remplacées par des appels à cette nouvelle API.

Il a aussi été évoqué l’intégration du composant natif NSPopOver

« Linux perf for Qt developers » par Milian Wolff



Présentation de l’outil perf du noyau Linux dans un contexte de développement d’une application reposant sur Qt pour une carte ARM. Les versions que l'on peut obtenir depuis le gestionnaire de paquets sont souvent obsolètes. Il a donc été conseillé de compiler soi-même perf pour pouvoir disposer des dernières fonctionnalités et corrections de bogues.

Milian Wollf maintient une branche personnelle du noyau Linux avec des patchs pour perf qui ne sont pas encore disponibles dans la branche officielle : www.github.com/milianw/linux.git

En tant que débutant avec perf, on peut rencontrer plusieurs obstacles :

  • des problèmes de permissions. Il existe un script Bash qui s’assure que les différents dossiers ont les bons droits pour que tout se passe correctement ;
  • la variable CC doit uniquement contenir le nom du compilateur, en aucun cas des chemins vers quelque en-tête que ce soit. Par ailleurs, clang ne fonctionne pas ;
  • il faut utiliser EXTRA_CFLAGS, CFLAGS est apparemment ignoré.


QTestLib propose un support basique de perf, le nombre d’itérations à effectuer peut être donné en argument :
Code : Sélectionner tout
./my_qt_test -perf -iterations 42
Par défaut, l’interface textuelle de perf est loin d’être optimale, certaines informations sont redondantes, alors que d’autres, pourtant très utiles au développeur, manquent :
Code : Sélectionner tout
perf report—no-children -s dso, sym,srcline -g address
flamegraph.pl permet de générer un fichier SVG, ce qui permet de visualiser facilement les endroits lents ou peu performants du code.

Le profilage des applications QML est un peu plus complexe à cause du JIT qui empêche de remonter les appels. Cependant, avec le LBR (Last Branch Record), ce problème peut être partiellement contourné. Avec une variable d’environnement, ce problème peut être résolu.
Code : Sélectionner tout
QV4_PROFILE_WRITE_PERF_MAP=1 perf record –call-graph lbr – qml my_app.qml


« Qt 3D Basics » par Kevin Ottens

Présentation de Qt 3D : ce n’est pas conçu comme un moteur de jeu, même si cela est totalement possible en pratique. Conçu pour intégrer du contenu 3D dans des applications reposant sur Qt, en permettant d’afficher des composants de GUI (boutons, champs de texte). Quelques explications sur l’architecture du code, qu’est-ce que le pattern ECS (Entity Component System), quels sont ses avantages dans le cadre d’un tel projet.

Quelques démonstrations reposant sur l’interface QML, un donut que l’on peut manipuler avec la souris, un cube que l’on peut faire tourner et grossir, puis des exemples plus complexes, qui faisant partie du matériel de formation de KDAB, ne seront vraisemblablement pas disponibles.



Qt 3D peut aussi être utilisé pour effectuer des simulations physiques.

Les API C++ et QML sont identiques, chaque classe C++ QMaClasse est disponible sous le nom MaClasse en QML.

Puis les nouveautés à venir :




« Qt Project Status » par Lars Knoll

Rappel des progrès accomplis depuis la sortie de Qt 5.0, une nouvelle version tous les 6 mois en moyenne. Explication sur le changement de licence. Le nombre de rapports de défauts ouverts avec une priorité P0, P1 et P2 (c'est-à-dire des problèmes relativement critiques qui touchent un grand nombre d'utilisateurs) augmente, les développeurs font face à une charge de travail très importante.

Présentation de COIN et de RTA (Release Test Automation), respectivement le système d’intégration continue et le système de tests des installeurs générés par le premier. Les besoins en ressources augmentent constamment au fil des nouvelles versions, avec toujours plus d'OS à supporter. La version supportée à long terme 5.6 n’arrange rien à cette situation.

Présentation de Qt Lite, beaucoup de clients ont besoin d'une base plus légère, avec seulement un sous-ensemble des fonctionnalités du framework.

Qu’en est-il de Qt 6 ? Pas avant 2019, mais sûrement plus tard. Qt 6 devrait reposer sur C++17, conserver une grande compatibilité au niveau des sources avec Qt 5.X. Par ailleurs, la dernière version de Qt 5.X devra être supportée à long terme. Dans 5.9, Python devrait faire son retour. Pour 5.10, devrait faire la part belle au « cloud » et aux services connectés, sans que rien de concret ne soit annoncé. Cette version devrait aussi être l’occasion de corriger de nombreux détails et d’améliorer l’expérience développeur.



Ensuite, Lars Knoll a présenté les objectifs à long terme de Qt, module par module :

  • Qt Core : alléger, alléger, alléger... Certaines fonctionnalités devraient être déplacées dans d’autres modules. Par ailleurs, le Meta Type System et le Moc devraient occuper les développeurs, ce dernier pouvant être plus rapide qu’il ne l’est actuellement ;
  • QtN etwork : détection des appareils et/ou services, zeroconf a été évoqué ;
  • Qt GUI/QPA : réduire la dépendance à OpenGL, support d’autres API graphiques comme Direct3D 12 ou Vulkan, OpenGL streaming, support de l’affichage à distance (Remote Display Support), support de Wayland pour le bureau Linux ;
  • QML : possible intégration de fonctionnalités issues d’ECMAScript6, évaluation paresseuse des liaisons, compilation en avance (en cours avec 5.8 et la mise en cache), amélioration du ramasse-miettes  ;
  • Qt Quick : nouveau système de gestion des événements (déjà en place dans 5.8), stabiliser et optimiser l'existant, hypothétique support de Vulkan et de la 3D sans dépendre de Qt 3D.


Au niveau de l’outillage, cela tournait beaucoup autour de clang, tant pour compiler que pour analyser le code. La distribution de clang dans les installeurs pour Windows a été évoquée, cela permettrait d’avoir un seul compilateur pour les différentes plates-formes. Le support de CMake doit par ailleurs être amélioré.

Le support de Python va devenir officiel, mais il reste encore beaucoup à faire. Shiboken, l’outil qui permet de générer le code Python de lien avec l'implémentation C++, a du mal à gérer la base de code qui contient de plus en plus de C++11, c'est dans ce contexte que fut évoqué clang pour l'analyse de code. PySide devient un projet à part entière du Qt Project avec le Desktop en ligne de mire. Les systèmes mobiles pourraient être supportés, mais ce n’est pas à l’ordre du jour.

Systèmes d’exploitation et compilateurs supportés :
  • Win8/WinRT ne devraient plus être gérés à partir de 5.9, même si ce n’est pas officiel ;
  • VS13 devrait aussi être abandonné avec 5.10 (présenté comme le pire compilateur actuellement supporté par Qt).

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

Avatar de arnolddumas
Rédacteur/Modérateur https://www.developpez.com
Le 06/09/2016 à 16:46
Citation Envoyé par air-dex Voir le message
En bref, les UWP de Windows 10 dépendent de Qt for WinRT. Du coup je les vois mal retirer "Qt for WinRT" de Qt dans un avenir proche. Je veux bien croire à l'arrêt du support de Windows (Phone) 8(.1) ainsi que de Windows RT, mais pas à l'arrêt pur et simple de "Qt for WinRT", et donc des UWP par voie de conséquence.
De ce que j'ai compris, cela est du au projet ANGLE (conversion des appels OpenGL en appels DirectX).

Le passage est disponible (35:37) : https://live.dus.c3voc.de/relive//qt.../354/muxed.mp4

Citation Envoyé par mintho carmo Voir le message
Merci pour les comptes rendus.

Les videos sont deja dispo : http://streaming.media.ccc.de/qtcon16/relive/ (je ne sais pas trop c'est quoi ce site, mais les videos devrait probablement etre dispo aussi sur la chaine youtube de Qt plus tard)
Il avait malheureusement fallu attendre des mois pour les précédentes éditions des Qt Developer Days.

PS : c'est le site du Chaos Computer Club, très réputé en Europe germanophone, notamment pour l'organisation du Chaos Communication Congress.
1  0 
Avatar de mintho carmo
Membre averti https://www.developpez.com
Le 05/09/2016 à 17:24
Merci pour les comptes rendus.

Les videos sont deja dispo : http://streaming.media.ccc.de/qtcon16/relive/ (je ne sais pas trop c'est quoi ce site, mais les videos devrait probablement etre dispo aussi sur la chaine youtube de Qt plus tard)
0  0 
Avatar de air-dex
Membre expert https://www.developpez.com
Le 06/09/2016 à 1:33
Citation Envoyé par arnolddumas Voir le message
Systèmes d’exploitation et compilateurs supportés :
  • Win8/WinRT ne devraient plus être gérés à partir de 5.9, même si ce n’est pas officiel ;
  • VS13 devrait aussi être abandonné avec 5.10 (présenté comme le pire compilateur actuellement supporté par Qt).
En lisant l'article, je me posais la question de Windows 10 et de ses applications universelles parmi les plateformes supportées par Qt. Encherchant un peu, je suis tombé sur l'article suivant, datant de début juillet : Status Update on Qt for WinRT / UWP. J'y ai lu ceci :

Citation Envoyé par Qt Blog
Supported Platforms

WinRT as a platform API set has been continuously improved and new features have been added which Qt can make use of, allowing us to provide more of Qt API to developers. One example is drag and drop support.

Many of you might have heard of the terminology Universal Windows Platform, or UWP. This describes a rather high level abstraction, in the end it boils down to the WinRT API being used and extended. Hence, the Qt for WinRT version currently supports the following platforms:
  • Windows 8.1
  • Windows Phone 8.1
  • Windows 10
  • Windows 10 Mobile
  • Windows 10 IoT (Core/Professional) *
  • Microsoft Hololens *
  • XBOX One *
En bref, les UWP de Windows 10 dépendent de Qt for WinRT. Du coup je les vois mal retirer "Qt for WinRT" de Qt dans un avenir proche. Je veux bien croire à l'arrêt du support de Windows (Phone) 8(.1) ainsi que de Windows RT, mais pas à l'arrêt pur et simple de "Qt for WinRT", et donc des UWP par voie de conséquence.
0  0 
Avatar de Jiyuu
Rédacteur/Modérateur https://www.developpez.com
Le 06/09/2016 à 7:01
Bonjour à tous,


« Qt 3D Basics » par Kevin Ottens
C'est un peu hors sujet, mais j'ai eu la chance de faire une semaine de formation Qt avec Kevin ... il envoie du lourd et très très sympathique.

Merci pour tes CR Arnold et pour le temps que tu y accordes.

Bonne continuation.

J
0  0 
Avatar de air-dex
Membre expert https://www.developpez.com
Le 07/09/2016 à 2:05
Citation Envoyé par arnolddumas Voir le message
« Making QML optional », par Andrew Knight

Problématique : les applications complexes reposant sur Qt Quick/QML rencontrent des problèmes de performances, de la lenteur, notamment au démarrage. En effet, tout le code QML doit être lu et compilé. L'idée de base est de prendre les classes de Qt Quick et de les exposer via une interface C++.

Le temps de création de la version C++ de l'interface est beaucoup plus rapide. Les temps de rendu sont les mêmes. Avec Qt Quick 1, la création de chaque bouton entraîne la création de nombreux QObject. Qt Quick 2 est bien plus efficace. L’implémentation maison ne nécessite qu'un seul QObject par bouton.

Discussion sur des classes permettant d'exposer des fonctions de dessin de bas niveau avec Qt Quick.
Personnellement j'ai toujours trouvé ça dégueulasse de manipuler du QML côté C++. Il me semble plus lisible et compréhensible d'exposer et d'utiliser des interfaces C++/QML dans le code QML (via des joyeusetés comme qmlRegisterType(); dans le main();) plutôt que d'aller directement attaquer le composant QML je ne sais où côté C++ (avec des joyeusetés comme QQmlEngine, QQmlContext et autres QQmlComponent). Certes c'est moins performant, mais si les performances sont (très) importantes alors autant faire du 100% C++ avec ce bon vieux Qt Widgets, non ?
0  0 
Avatar de arnolddumas
Rédacteur/Modérateur https://www.developpez.com
Le 07/09/2016 à 8:27
De ce qu'il a été présenté, il s'agissait plus de prouver la faisabilité et de mesurer les performances que de vraiment développer une technologie aboutie. De l'avis meme du presentateur, les chiffres ne sont pas forcement fiables car mesurant parfois des choses différentes, de plus, son implémentation reposait sur une version ancienne de Qt (quelque chose comme 5.4 si je me souviens bien).
0  0