Developpez.com

Club des développeurs et IT pro
Plus de 4 millions de visiteurs uniques par mois

QtCon, deuxième journée
Les systèmes d'intégration continue et de compilation pour Qt, le développement mobile, un compte-rendu d'Arnold Dumas

Le , par arnolddumas, Rédacteur/Modérateur
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.


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de mintho carmo 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)
Avatar de air-dex air-dex - Membre émérite 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.
Avatar de Jiyuu 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
Avatar de arnolddumas arnolddumas - Rédacteur/Modérateur https://www.developpez.com
le 06/09/2016 à 16:36
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.



Selon la documentation, QObject est réentrant mais, en pratique, cela est faux.



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.





« 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.
Avatar de arnolddumas 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//qtcon16/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.
Avatar de air-dex air-dex - Membre émérite 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 ?
Avatar de arnolddumas 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).
Offres d'emploi IT
Ingénieur produit (Landing gear) H/F
Safran - Ile de France - MASSY Hussenot
Ingénieur développement logiciels temps réel embarqué H/F
Safran - Ile de France - Éragny (95610)
Ingénieur moa logiciel H/F
Safran - Ile de France - Villaroche

Voir plus d'offres Voir la carte des offres IT
Responsable bénévole de la rubrique Qt : Thibaut Cuvelier -