QtCon - la conf�rence d�di�e � Qt, KDE et VLC � Berlin

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



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 - Visualiser dans une fen�tre � part

./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 - Visualiser dans une fen�tre � part

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 - Visualiser dans une fen�tre � part

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).

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)

Envoy� par arnolddumas

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 :

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.

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.

Envoy� par air-dex

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

Envoy� par mintho carmo

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.

Envoy� par arnolddumas

� 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 ?

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).