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, 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

0PARTAGES

5  0 
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.

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