L’environnement Qt, racheté par Digia à Nokia, subit une évolution majeure avec l’arrivée de la version 5.0. De nombreuses nouveautés sont au programme ainsi qu’une hausse des performances dans plusieurs cas.
Qt est pour rappel un environnement de développement multiplateforme. L’objectif est simple : permettre aux développeurs d’écrire un code qui pourra ensuite être utilisé de la même manière sur l’ensemble des systèmes d’exploitation. On pourrait ainsi citer les cas connus de VirtualBox d’Oracle ou encore de VLC.
La nouvelle version 5.0 apporte de nombreux nouveaux éléments, certains particulièrement importants. Qt Quick par exemple, qui permet la création d’interfaces utilisateur personnalisables, gère désormais pleinement l’OpenGL. Cela signifie pour les développeurs de nouvelles possibilités dans l’utilisation des effets ou l’intégration de contenus 3D. Sont également présents un système de gestion des particules ainsi qu’une collection d’effets shader préconstruits.
Digia annonce également que le moteur QML a été très largement amélioré et que la version 11 du C++ est supportée. La présence de QTWebKit 2 permettra de son côté aux développeurs de manier le HTML5. En outre, Qt 5 doit apporter une nette amélioration des performances, en particulier sur les équipements dont les ressources sont limitées. L’entreprise cite le cas des smartphones, des tablettes et des plateformes de développement telles que le Pi de Raspberry.
La vidéo ci-dessus présente globalement les nouveautés de Qt 5 et a d’ailleurs été réalisée entièrement avec les technologies de ce dernier pour en faire une démonstration.
L’éditeur précise en outre que le travail de modularisation de Qt a porté ses fruits. L’environnement se découpe désormais en un nombre d’éléments dits « essentiels » accompagnés par un lot de plug-ins qui sont, eux, optionnels. Moins les plug-ins seront nécessaires au développeur, plus le poids de son application sera réduit.
Enfin, la migration pour les applications actuelles est censée être simplifiée. Selon Digia, une simple recompilation doit suffire. Notez qu’il s’agit de la première version majeure de Qt depuis le rachat de la technologie.
Les développeurs intéressés pourront récupérer Qt 5 depuis le site officiel. La version commerciale peut être essayée pendant 30 jours gratuitement. Qt 5 est compatible avec Windows, OS X et Linux côté ordinateurs, ainsi que Linux et Windows Embedded pour les équipements embarqués classiques, ou VxWorks, Neutrino et INTEGRITY pour les systèmes temps réel embarqués. La compatibilité Android et iOS sera ajoutée par la suite.
Commentaires (58)
#1
Qt comme Quicktime ou aucun rapport ?
#2
#3
#4
Quid des performances sur Android ou iOS ? J’ai un peu du mal à imaginer le truc :/
#5
#6
Faudrait que j’me documente, comme l’API est en java, la conversion C++/Java, et je suis loin d’être un expert, c’est là que je suis un peu perdu
" />.
Merci de ta réponse
#7
#8
Est-ce qu’il y a un site ou on peut comparer Qt et wxWidgets ?
#9
#10
#11
#12
brazomyna a écrit
Plus sérieusement, Qt n’est pas qu’une librairie pour fournir quelques widgets graphiques pour monter des IHM d’applis desktop, c’est beaucoup beaucoup plus que ça. On peut parfaitement utiliser Qt pour faire un démon de serveur cross platform par exemple (j’en ai déjà fait dans un contexte pro).
Donc ça va être difficilement comparable à WxWidget qui -lui- est spécialisé là dedans uniquement puisque c’est une ‘lib pour faire des GUI’.
Je sais. Il y a un projet qui vise à ce que Audacity utilise Qt à la place de wxWidgets et ce n’est pas évident.
#13
Ceux qui bossait sur le projet Necessitas (port de Qt sur Android) travaillent maintenant pour Digia et contribue à Qt Project.
#14
La version commerciale peut être essayée pendant 30 jours gratuitement.
Quelles sont les modalités de la licence SVP ?
Quand j’ai fait mon choix de toolkit graphique (en 2006-2007), j’avais été séduit par Qt qui offrait un très grand choix de composants mais rebuté par sa licence qui - à l’époque - était assez restrictive, et j’avais choisi WxWidgets au final.
#15
Parfaite nouvelle ! J’ai commencé à dev grâce à Qt … Aujourd’hui j’ai mon boulot grâce à Qt
" />
#16
#17
#18
IAmNotANumber a écrit :
Quelles sont les modalités de la licence SVP ?
Quand j’ai fait mon choix de toolkit graphique (en 2006-2007), j’avais été séduit par Qt qui offrait un très grand choix de composants mais rebuté par sa licence qui - à l’époque - était assez restrictive, et j’avais choisi WxWidgets au final.
Au pire, Qt est sous licence LGPLv2 depuis la version 4.5 ce qui fait qu’on peut l’utiliser dans un logiciel propriétaire. Cela veux dire que tu peux utiliser Qt dans un logiciel propriétaire sans avoir à payer la licence commercial (sans avoir le support/service, les Qt solutions et la possibilité de linker Qt statiquement)
#19
#20
#21
Qt est intéressant car il permet de s’abstraire de l’OS au point de vue:
Après c’est chacun ses choix, moi en ce moment c’est la STL + Boost + wxWidgets 2.9 (uniquement pour la GUI)
#22
#23
#24
J’ai été embauche aux US parce que je connaissais Qt et j’etais au Qt DevDays 2012 au début du mois de Decembre.
La difficulte pour Qt sur Android est la mise en place des libraries dans le systeme.
Necessitas utilise un launcher qui s’appelle Ministro et qt va verifier si les lib Qt sont la ou pas et va les d/l le cas echeant. le probleme est que ca la fout mal de lancer une appli et d’avoir un autre truc qui demande de d/l des lib avant de lancer l’appli
je ne sais pas encore comment ils vont résoudre ca sans qu’on ai a embarquer les lib dans l’appli (et hop 30Mo l’appli).
Tout les système embarque sur lesquel on dev sont sous Qt, (Frigo, machine a laver), tout mes projet perso sont fait avec Qt (prise de tete en moins).
Je ne sais pas si j’arriverais un jours a me réadapter a un environnement non Qt.
Quand je vois des gens utiliser des librairies multiples comme wxWidgets, Boost, etc.. et l’idée d’avoir ca en multiplateforme (Win/OSX/Linux), ca me donne mal au crane.
#25
Vu qu’il y a des connaisseurs, est-ce que QT vous semble intéressant pour faire une appli qui doit tourner sur des NAS type QNAP/Syno etc… ?
#26
tout depend du NAS, tout depend de l’appli.
Un Nas c’est juste une linux box custom dans un beau package facile a utiliser.
En general les constructeurs fournissent un SDK pour integrer des app dans leur interface/system. (je crois que c’est le cas pour syno)
Vu que les librairies Qt ne sont pas installe d’office avec un système, il faut souvent installer (sauf si tu as une licence commercial pour les compiler en statique dans ton app), ce qui veut dire qu’il te faut un accès a un terminal en root sur la machine et a ce niveau la on retombe sur de l’environnement embarque classique.
Dans le cas d’un soft console (daemon par ex).
Il n’y a rien que tu puisse faire sur Qt que tu ne puisse pas faire avec la STL, Qt te fais simplement gagner du temps sur le dev et les bug (genre la gestion UTF-8) et fournit une interface standardise (qt-creator) avec l’ensemble de la team de dev.
le fait que Qt soit intéressant est purement subjectif, question d’habitude (y en a qui prefere .net et C#).
Si tu as un environnement qui marche avec Qt ou bien (dans le cas d’un NAS), tu sais comment faire pour déployer Qt avec ton app, alors oui Qt est intéressant parce que tu aura un environnement solide.
#27
la version 11 du C++
2011 plutôt non ? Sinon C++11 suffira.
#28
#29
Petite discussion sur le sujet (OpenGL) :http://www.developpez.net/forums/d1290911/c-cpp/bibliotheques/qt/qt-5-0-0-versio…
#30
#31
#32
Pour compléter ce que je disais un peu plus tot, je me permet de recopier ici mon retour d’experience:
Je viens de porter un gros projet (SpectraLayers) de Qt 4.8/MinGW/OpenGL à Qt 5.0/MSVC/OpenGL ES. Le tout sous Qt Creator.
Le passage de Qt 4.8 à Qt 5.0 n’a pas été une grosse difficulté: quelques fonctions ont été déplacés de classe, et certaines classes ont été renommés, mais grosso modo c’est allé assez vite (98% du code est resté tel quel).
Il faut juste piger que le partitionnement des modules n’est plus le même, par exemple les widgets ne font plus partie du module Gui mais du nouveau module Widget, et donc changer quelques headers globeaux/librairie Qt necessaire au projet.
Pour ceux qui créent des plugins, la déclaration des plugins a aussi légèrement changé, on passe de Q_EXPORT_PLUGIN2 à Q_PLUGIN_METADATA (qui n’ont pas exactement les mêmes paramètres).
A noter aussi la disparition de setAlphaChannel, il faut recréer son propre équivalent.
Le passage de MinGW à MSVC a été un peu plus compliqué, par exemple j’avais quelques sous-projets dans mon code principal qui n’étaient pas compris par MSVC, j’ai du simplifier la structure du projet en transformant mes sous projets du code principal en projets de librairies statique de meme niveau que le projet principal, et lier ces librairies statique à mon code principal.
Il a fallut d’autre part convertir certaines directives de compilation et de déclaration de fonctions propres à gcc, mais j’en avais peu dans mon code. Pour faire la distinction, dans le code c++ j’ai des:
#ifdef __GNUC__
Et dans mon projet .pro:
win32-g*|mac:QMAKE_CXXFLAGS += …
win32-msvc*:QMAKE_CXXFLAGS += …
Il y avait aussi quelques warnings qui sont apparus, mais juste des problèmes mineurs.
Au niveau des perfs c’est à peu près équivalent, voire même un peu gagnant par endroit, par contre j’ai remarqué que MSVC gérait mal l’optimisation de boucles for(;;) compliqués, j’ai du remplacer certaines boucles critiques par un déroulement while(count–) { } simplifié pour retrouver de bonnes perfs (ceci dit j’aurai certainement gagné aussi un peu en perf avec MinGW je suppose).
Enfin, le passage de OpenGL à OpenGL ES a été vraiment galère. Mais quelque part c’est un mal pour un bien, dans la mesure ou OpenGL ES est une version simplifié d’OpenGL ça oblige à repenser de manière un peu plus simple sont code OpenGL (je faisais jusque là allègrement usages de tricks OpenGL en tout genre, y compris de fonctions obsolètes). Heureusement le framework Qt est la pour nous accompagner dans le développement OpenGL ES en fournissant quelques fonctions qui font gagner du temps.
Je dois souligner d’ailleurs que j’ai fait en sorte que mon nouveau code soit compatible à la fois avec OpenGL ES et OpenGL, dans la mesure ou Qt 5 sur mac (mon logiciel est compilé sur mac aussi) utilise toujours OpenGL.
Pour cela, dans mes shaders j’ai rajouté l’entête suivante:
#ifdef GL_ES
precision highp float;
#endif
Et j’ai créé le header suivant pour avoir certaines fontions/variables compatibles GL/GL ES:
#ifndef GLESCOMP_H
#define GLESCOMP_H
//OpenGL/ES2 Compatibility
#include
#ifdef QT_OPENGL_ES_2
#define GLENABLETEX2D
#define GLRGBA32F GL_RGBA
#define GLALPHA32F GL_ALPHA
#define GLLUMINANCE32F GL_LUMINANCE
#else
#define GLENABLETEX2D glEnable(GL_TEXTURE_2D);
#define GLRGBA32F GL_RGBA32F_ARB
#define GLALPHA32F GL_ALPHA32F_ARB
#define GLLUMINANCE32F GL_LUMINANCE32F_ARB
#endif
#endif // GLESCOMP_H
A noter que la signification des paramètres de textures en OpenGL ES n’est pas la même qu’en OpenGL ! Pour envoyer des textures float en OpenGL le code est le suivant:
glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA32F, width, height, 0, GL_RGBA, GL_FLOAT, data);
glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA16F_ARB, width, height, 0, GL_RGBA, GL_FLOAT, data);
glTexImage2D(GL_TEXTURE_2D, 0, GL_ALPHA32F_ARB, width, height, 0, GL_ALPHA, GL_FLOAT, data);
glTexImage2D(GL_TEXTURE_2D, 0, GL_ALPHA16F_ARB, width, height, 0, GL_ALPHA, GL_FLOAT, data);
Alors qu’en OpenGL ES il faudra écrire:
glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA, width, height, 0, GL_RGBA, GL_FLOAT, data);
glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA, width, height, 0, GL_RGBA, GL_HALF_FLOAT_OES, data);
glTexImage2D(GL_TEXTURE_2D, 0, GL_ALPHA, width, height, 0, GL_ALPHA, GL_FLOAT, data);
glTexImage2D(GL_TEXTURE_2D, 0, GL_ALPHA, width, height, 0, GL_ALPHA, GL_HALF_FLOAT_OES, data);
Ceci dit en utilisant les defines du header de compatibilité que j’ai créé ci-dessus, il y a moyen d’avoir strictement la même écriture dans les 2 cas.
Mon seul regret est la disparition des Pixel Buffer Object (qui ne sont réintroduits que dans OpenGL ES 3), bien pratiques pour faire des transferts rapide de textures, j’ai du compenser en renvoyant mon architecture globale.
Je n’ai pas encore tout à fait finit le portage OpenGL mais le code minimal fonctionnel est en place, il ne faut pas hésiter à s’inspirer des exemples opengl fournis dans le SDK (qui sont pour la plupart compatibles OpenGL/OpenGL ES).
Au final j’ai du passer 10% du temps sur le passage Qt 4.8->Qt 5, 20% sur MinGW->MSVC, et 70% sur OpenGL->OpenGL ES (restructuration complète oblige).
En espérant que ce retour puisse vous éclairer !
#33
c’est bien beau qt5 mais j’ai pas trouvé de lien vers un qt creator+compilo gratuit c’est normal? qt voudrait il rendre payant son offre :o
#34
mattox37 a écrit :
c’est bien beau qt5 mais j’ai pas trouvé de lien vers un qt creator+compilo gratuit c’est normal? qt voudrait il rendre payant son offre :o
Clang
#35
http://qt-project.org/downloads
" />
Les compilos sont gratuits évidemment… Mais si tu veux l’utiliser directement sans recompiler avec MinGW ou autre, donc avec MSVC, il te faut installer la version Express qui est gratuite. Dans Qt 5.0.1 on devrait retrouver la version MinGW…
@divide : Hors sujet mais au lieu de for(;;), c’est carrément plus classe et poétique d’utiliser la magnifique macro “forever”
#36
for(;;) c’etait juste une manière schematique d’écrire (j’avais plein de variables dans ce for justement, ce qui causait les ralentissements avec MSVC).
Par contre je ne connaissais pas la macro forever, tu m’as appris un truc la !
#37
Ne pas oublier GTK+ et les EFL.
#38
#39
#40
Et toujours pas de support des périphérique de jeu…
" />
#41
C’est vrai que c’est un peu ballot qu’il n’y ai pas de classe QJoystick…
#42
#43
#44
Sans parler de la valeur ajoutée, avec une documentation super complète et l’IDE multiplateforme de Qt, Qt Creator…
#45
#46
#47
#48
#49
#50
#51
#52
#53
#54
#55
#56
#57
#58