Version imprimable
:salut:
Je serais présent à la QtCon à Berlin, qui se déroule du jeudi au dimanche. Si d'autres membres sont présents, ça serait sympa de se rencontrer sur place ou de prendre une bière quelque part.
Pour ceux qui ne peuvent pas y assister, je compte faire une sorte de reportage, avec photos et informations des sessions auxquelles je prendrais part.
++
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
Pièce jointe 219506
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 :
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:./my_qt_test -perf -iterations 42
flamegraph.pl permet de générer un fichier SVG, ce qui permet de visualiser facilement les endroits lents ou peu performants du code.Code:perf report—no-children -s dso, sym,srcline -g address
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.
Pièce jointe 219504Code: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.
Pièce jointe 219510
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 :
Pièce jointe 219508
Pièce jointe 219509
« 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.
Pièce jointe 219505
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).
Deuxième journée de conférence, avec deux sessions orientées développement Android/iOS.
« Coin Mining » par Jedrzej Nowacki
Présentation du système d’intégration continue Coin. Avec 250 développeurs actifs, il est impératif d’avoir un système d’intégration continu en place, afin de s’assurer de la qualité du code. Jedrzej Nowacki a fait un rapide historique, en remontant jusqu’à l’époque Trolltech :
- « whip approach » ou « politique du fouet ». Une personne est responsable des tests et s’assure que ces derniers s’exécutent correctement. Lorsqu’un test ne passe plus, cette personne notifie le développeur responsable ;
- avoir deux branches, une de développement et une autre stable. En pratique, cela ne fonctionne qu’un temps, car on se retrouve vite à avoir une branche à jour et une autre jamais maintenue ;
- introduction de Gerrit et de Jenkins, le plus gros changement dans l’histoire de l’assurance qualité de Qt. Grâce à ces deux logiciels, le code qui est intégré compile et les tests passent toujours ;
- puis développement de COIN, développé en interne chez The Qt Company, toujours en se basant sur Jenkins.
D’un point de vue technique, Coin repose actuellement sur vSphere, Git et Jenkins, mais pourrait être portée sur CloudStack ou une autre solution similaire. Il est même probable de passer sur une autre technologie de virtualisation, car vSphere ne satisfait pas pleinement ses développeurs.
À court et moyen terme, différents développements sont prévus :
- nouveau système de virtualisation, abandon à plus ou moins long terme de vSphere ;
- possiblement rendre disponible Coin sous une licence open source. Coin a été conçu dès le départ comme un projet générique, pas uniquement pour Qt. Même s’il y a des dépendances comme fortes comme Git, le projet ne dépend ni de Jenkins ni de vSphere. Des contributions dans ce sens pourraient être acceptées ;
- « CI command bot », une interface en ligne de commande, pour tester des configurations spécifiques ou un système d’exploitation en particulier avant que le code ne soit proposé sur Gerrit ;
- support de différents appareils, dans le but de faire tourner les tests sur des appareils physiques ;
- exécution distribuée des tests, faire tourner la moitié des tests sur une machine et le reste sur une autre, afin de paralléliser et de gagner un temps précieux ;
« Qt Build systems » par Kai Köhne
Présentation sous forme de BoF (ou encore « unconference »), discussions entre différents utilisateurs et développeurs de Qt. Pour le moment, trois systèmes de compilations cohabitent lorsque l’on parle de Qt : QMake, CMake et Qbs.
Le premier, QMake, est de l’avis de beaucoup un mort-vivant : il survit. Il reste le système de compilation par défaut lors de la création d’un nouveau projet Qt et est lui-même utilisé pour compiler Qt ainsi que Qt Creator. Cependant, il ne faut pas s’attendre à de gros développements.
CMake est un système de compilation générique, maintenu par la communauté et par l’entreprise Kitware. Il est très utilisé dans le monde C++, par le projet KDE ou Blender par exemple. Il est relativement facile d’utiliser CMake pour compiler un projet reposant sur Qt. Par ailleurs, de nombreuses bibliothèques annexes sont supportées.
Enfin, Qbs (prononcez « Cubes »), qui n’est plus l’acronyme de Qt Build System, développé par The Qt Company. Contrairement aux deux précédents, Qbs n’est pas un générateur de Makefile. Pour l’instant, seul Qt Creator peut être compilé avec Qbs, il reste encore du travail pour pouvoir compiler Qt avec ce dernier.
Étant donné que QMake est un mort-vivant, la question était de savoir lequel des deux autres serait le meilleur remplaçant. Les développeurs étaient d’avis divergents quant à l’impact du système de compilation utilisé par Qt lui-même sur celui qui serait utilisé pour des applications utilisant Qt. Il serait en effet difficile d’utiliser CMake en interne, tout en faisant la promotion de Qbs et inversement. Aucune décision ne fut prise.
Quoi qu’il en soit, quasiment tous les développeurs présents dans la salle utilisaient CMake pour leurs projets, la seule solution présentée comme « réaliste » pour un projet C++ à l’heure actuelle. Le système de compilation sur lequel repose Qt influence les utilisateurs de Qt.
« Continuous tests and distribution for Qt applications on desktop and mobile » par Nicolas Froment
Session en forme de retour d’expérience de la part d’un des développeurs principaux de MuseScore, un éditeur de partition, disponible pour Linux, macOS, Windows, iOS et Android. Il y a deux bases de code, une pour le bureau, une pour le mobile. Le code pour le bureau est libre, tandis que le code pour l’application mobile est propriétaire. Les deux plates-formes ont des attentes différentes quant aux fonctionnalités.
Après un bref passage en revue des différentes solutions existantes, Travis CI fut retenu. Il existe une offre gratuite pour les projets open source et l’intégration avec Github est totalement opérationnelle : il suffit d’avoir un fichier travis.yml à la racine du dépôt Git.
Il est possible de publier automatiquement les binaires testés sur différents supports : Google Play, Apple Store, S3. Extrêmement pratique, car faire télécharger un fichier APK aux testeurs est peu pratique. Pour Windows, on peut par exemple mettre en ligne un installeur et pour macOS une archive DMG. Plus le logiciel est facile à tester, plus il y aura de testeurs, donc meilleure sera la qualité du projet et du code.
Cependant, Travis impose différentes limites, notamment au niveau du temps alloué pour compiler et tester son projet :
C’est pour cela qu’il est important de réduire le temps nécessaire à la compilation, ce qui peut se faire grâce à différents outils et pratiques selon le projet.
Il ne faut stocker ni mot de passe ni clefs de licence directement dans le dépôt Git. Au contraire, il faut utiliser les fonctions de Travis pour ce faire, comme « Encryption Key », comme décrit dans la documentation.
Par ailleurs, il est fortement conseillé de confier la gestion et l’installation des dépendances au gestionnaire de paquet. Mais il arrive que les dépendances nécessaires ne soient pas encore disponibles, car les machines virtuelles proposées peuvent dater. Dans ce cas, il faudra télécharger l’installateur sur le site dudit projet et exécuter l’installateur depuis un script shell.
Même si cela paraît simple, il est en fait complexe d’utiliser l’installateur de Qt si l’on ne possède pas d’interface graphique. Il s’avère néanmoins qu’une personne de la communauté a développé un script permettant de réaliser cette tâche.
« Going all-in with Qt on mobile », par Kai Uwe Broulik
Tout est parti d’un client possédant une application Android dont le code était trop obscur pour pouvoir être maintenue. Lors du redéveloppement de cette application, une version iOS était aussi souhaitée.
Le client demandait différentes fonctionnalités non intégrées pour le moment, comme :
- deep link, un lien internet qui ouvre un contenu précis dans l’application ;
- les fonctions de partage via Facebook.
La plupart de ces fonctions ne sont pas directement mises à disposition par Qt, mais sont facilement utilisables. Ainsi, une surcouche QML a été développée par-dessus le SDK Facebook en moins de 150 lignes. Elle peut alors être réutilisée dans d’autres applications pour Android reposant sur Qt.
Le développement d’une telle application avec Qt est totalement faisable et l’application fut même propulsée dans le carrousel du Google Play (http://www.menshealth-personaltrainer.com/de/). Ce qui nécessite une notation supérieure à 4 et une apparence irréprochable.
Ce look-and-feel natif n’a cependant pu être atteint que par de nombreux bricolages et ajustements de la part de l’équipe de développement. Par défaut, le framework ne porte pas forcement attention aux détails. Par exemple, les polices de caractères, le bruit lors du clic, vitesse d’animation des composants.
Présentation très encourageante pour l’avenir quand on voit ce qu’il était possible de faire avec Qt il y a quelques années.
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)
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 arnolddumas
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.Citation:
Envoyé par Qt Blog
Bonjour à tous,
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.Citation:
« Qt 3D Basics » par Kevin Ottens
Merci pour tes CR Arnold et pour le temps que tu y accordes.
Bonne continuation.
J
QtCon, troisième journée
intégration de CMake à Qt Creator, multifil avec Qt, une interface Qt Quick sans QML, un compte-rendu d'Arnold Dumas
« CMake in Qt Creator (and elsewhere) », par Thobias Hunger
CMake est très utilise dans le monde C++ ; malheureusement, il est assez complexe de développer autour, car il fonctionne comme une sorte de boite noire. On donne un CMakeLists.txt en entrée et on obtient un de Makefile ou fichier projet en sortie. Par contre, il est difficile d’accéder à la représentation en interne du projet, notamment pour les EDI.
Le but est de développer une sorte de serveur, à qui on pourrait envoyer des requêtes sur le projet en cours. Par exemple, demander la liste de fichiers pour la cible « mabibliotheque » ou encore « monbinaire ».
La communication se fait via un protocole JSON, lisible avec le module du même nom de Qt 5. Le projet est plus ou moins fonctionnel à l’heure actuelle. Une intégration upstream est en discussion mais risque de durer.
Des développeurs d’autres EDI, notamment Milian Wolff et Kevin Funk, tous les deux de KDevelop, étaient aussi là pour présenter leurs problématique, et s’assurer que ce serveur soit le plus générique possible.
« Multithreading with Qt », par Giuseppe D'Angelo
Cette présentation avait pour thème la parallélisation en C++ avec Qt :
- QThread ;
- synchronsation ;
- thread safety avec Qt ;
- Qt et STL concernant le multi-threading.
QThread hérite de QObject : il n’est donc ni copiable ni déplaçable, possède des signaux et des lots et est conçu pour gérer un fil d’exécution.
On peut créer un fil d’exécution avec ou sans boucle évènementielle. Si l'on ne souhaite pas de boucle événementielle, on peut simplement hériter de QThread et réimplémenter la méthode run(), on démarrera alors le fil d’exécution avec QThread::start(). Pour un QThread avec boucle événementielle, on appellera la methode QThread::exec(). On utilisera alors quit() ou exit() pour sortir du fil d’exécution. On peut modifier la priorité du fil d’exécution par la méthode setPriority(). Il est aussi possible d'utiliser une QEventLoop ou d'appeler directement QCoreApplication::processEvent().
C’est une mauvaise idée d'appeler sleep() au sein d'un fil d’exécution. Il vaut mieux tirer parti des signaux et slots (ou alors utiliser le polling).
Il n’est pas possible d’effectuer des opérations affectant l’IHM depuis un autre fil d’exécution que le principal. Impossible d’utiliser QWidget/Qt Quick/QPixmap hors du fil d’exécution principal. Par contre, ce n'est pas gênant d'utiliser des QImage/QPainter.
Concernant OpenGL, cela dépend de la configuration. La méthode QopenGLContext::supportThreadedOpenGL() permet de savoir si le multithread est géré.
Il faut faire attention à ne jamais bloquer le fil d’exécution principal, qui se trouve être responsable de l’IHM : ne pas appeler sleep(). Faire attention à supprimer tous les QObject d'un fil d’exécution avant de le supprimer.
Pour s’assurer de la suppression des QObject à la fin du fil d’exécution, on peut :
- allouer les objets sur la pile ;
- connecter deleteLater au signal QThread::finished() ;
- déplacer les objets encore nécessaires dans le fil d’exécution principal (qApp->thread()).
Quand on parle de synchronisation, le mot-clé est : « data race ». Nécessite deux choses : au moins un des deux accès est une écriture et les accès ne sont pas atomiques, aucun accès n’ayant lieu avant l’autre.
Qt propose différentes classes pour synchroniser : QMutex, QSemaphore, QWaitCondition,, QReadWriteLock, QAtomicInt, QAtomicPointer<T>. Il y a aussi des classes RAII pour la gestion des verrous, comme QMutexLocker.
Une fonction est dite thread-safe si on peut appeler cette fonction au même moment, depuis différents fil d'exécution, sur les mêmes données, sans devoir synchroniser du côté développeur.
Réentrant : pareil que thread-safe mais sur des données différentes.
Non-réentrant (thread-unsafe) : fonction qui ne peut être appelée que depuis seul fil d’exécution à la fois.
Pièce jointe 219737
Selon la documentation, QObject est réentrant mais, en pratique, cela est faux.
Pièce jointe 219738
Alors, comment communiquer avec un QObject vivant dans une autre fil d’exécution ? Avec les connections multi-thread : QueuedConnection. Cela postera l'événement dans la boucle d’événement du fil d’exécution dans lequel vit le QObject receveur. L’objet receveur doit absolument vivre dans un fil d’exécution possédant une boucle d’événement. Les types passés en argument doivent être enregistrés via qRegisterMetaType.
Le type de la connexion est décidé uniquement au moment de l'émission du signal, sauf si le type est précisé lors de l'appel à QObject::connect().
Ce n'est pas un problème d’ajouter des signaux dans une sous-classe de QThread, mais ajouter des slots est le signe d'une mauvaise conception.
On peut sans souci combiner Qt et la bibliothèque standard (C++11) au niveau du multi-threading. Il est à noter que beaucoup d’outils peuvent vérifier le bon usage de l’API STL concernant le multithreading, mais ils ne fonctionnent pas avec Qt, à moins que l’implémentation de Qt ne repose sur la STL. QThread est plus pratique d’utilisation lorsque l'on travaille avec des QObjects.
À la fin de la session, les différents types venant de la STL et de Qt furent comparés.
Pièce jointe 219739
Pièce jointe 219740
Pièce jointe 219741
« 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.
De ce que j'ai compris, cela est du au projet ANGLE (conversion des appels OpenGL en appels DirectX).Citation:
Envoyé par air-dex
Le passage est disponible (35:37) : https://live.dus.c3voc.de/relive//qtcon16/354/muxed.mp4
Il avait malheureusement fallu attendre des mois pour les précédentes éditions des Qt Developer Days.Citation:
Envoyé par mintho carmo
PS : c'est le site du Chaos Computer Club, très réputé en Europe germanophone, notamment pour l'organisation du Chaos Communication Congress.
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 ?Citation:
Envoyé par arnolddumas
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).
