Bonsoir,
Dans ce cas, vous indiquez plutôt une approche Model/View, ce qui correspond plutôt à l'option "Complémenter avec du code C++/Python" si je ne m'abuse.
Note : dans ce post, je parle de C++, mais par rapport au sondage, considérez que les mêmes arguments sont valables pour une utilisation avec Python (même si les performances risquent d'être légèrement moins bonnes que C++).
Pour ma part, j'ai eu l'occasion dans le cadre professionnel de travailler sur des applications Allociné, Dailymotion et Marmiton à l'époque où Intel voulait lancer son app-up pour notebooks Windows 7 et tablettes MeeGo qui n'a semblerait-il d'ailleurs pas fonctionné. C'était à l'époque de Qt Quick 1.0, et les applications ont été développées à 95% en QML/JS, 5% restants étant en C++ pour le viewer et le code spécifique à l'app-up. On se basait sur les webservices des boîtes en question pour récupérer les informations (fiche de film/recette de cuisine/etc.), on parsait ça en JavaScript et intégrait ça dans les modèles QML, ce qui mettait à jour les vues. Et cela fonctionnait bien pour les applications que c'était. La seule partie moche du projet était le player vidéo : on avait fini par y aller salement en passant par un player Flash intégré dans une WebView QML qu'on contrôlait via des appels à evaluateJavaScript(), vu qu'à l'époque, Qt Multimedia n'en était qu'à ses débuts et que ce n'était pas très stable, et qu'on ne pouvait pas utiliser le player de la lib VLC à cause des contraintes de licences, d'autant plus qu'il y avait bien moins de ressources alors au sujet de la communication QML/C++. Toujours est-il qu'on avait des applications qui ne nécessitaient pas de logique C++ et que QML et JavaScript se suffisaient à eux-même, sans aucun problème de fluidité ou quoi que ce soit, et que le développement était très rapide pour des applications esthétiques (design personnalisé en rapport avec le design des applis des boîtes concernées, et ce sans passer mille ans à galérer sur des feuilles de style Qt Widgets) avec de belles animations.
Sur le plan de mes études, dès lors que le langage était libre et qu'il m'était demandé des applications possédant des interfaces graphiques, j'ai toujours choisi d'utiliser QML pour vraiment plonger dedans. Comme gros projet de groupe, on a eu l'occasion de développer une sorte de Skype avec gestion des groupes de conversation (texte, vocal, vidéo et partage d'écran), des contacts, etc. Côté serveur, rien de bien compliqué, du C++ classique avec boost pour faciliter le développement de la partie réseau. Il s'agissait par contre de communication QML/JS/C++ côté client. La partie C++ comportait la socket TCP vers le serveur et les sockets UDP vers les clients, et agissait en tant qu'interface entre le QML/JS et le réseau. À la réception d'un message, le C++ récupère le paquet, l'analyse et en forme une première structure C++ contenant les informations, puis les transforme en JSON et les envoie au QML qui s'en sert pour mettre à jour ses modèles via du JavaScript. À l'inverse, lors d'une action utilisateur (par exemple une demande de connexion), le JavaScript forme un message JSON, transmis au C++ qui l'analyse, le transforme en paquet via les structures C++ et l'envoie sur le réseau. Et cela fonctionnait bien.
À titre personnel, je travaille sur un projet de jeu (un Tactical RPG pour plateformes mobiles où on contrôle des unités tour par tour pour les envoyer affronter d'autres unités) et j'ai fait une erreur : je suis parti de la partie Core pour remonter vers la partie GUI. C'est-à-dire que j'ai codé en C++ des classes Unit, Map, etc., avec toute une API mais qui n'avait aucun moyen de s'intégrer facilement avec du QML que l'on doit plutôt voir de mon point de vue comme étant événementiel. L'intégration avec la partie GUI a été initialement terrible (je partais sur une duplication des données C++ vers les modèles QML par habitude) et, vu la quantité d'informations à stocker, le fait de garder l'interface graphique synchronisée avec la partie Core C++ s'est révélée trop compliquée. J'ai donc tout revisité, changé le code C++ pur en un code plutôt Qt, avec chaque classe dérivant de QObject et possédant des propriétés (comme les propriétés x/y pour les unités, permettant d'avoir leur emplacement sur la carte), permettant une meilleure intégration avec le QML. Moralité de l'histoire ? Et bien ça fait plus de deux ans que je suis sur ce projet (avec des phases de hauts et de bas en terme de temps de travail, laissant des mois pendant lesquels j'avais d'autres préoccupations), et il est loin d'être fini. Cela dit, cela m'aura tout de même permis de constater une chose : coder un projet hybride QML/JS pour la partie graphique/interactions utilisateur et C++ pour la logique nécessite que le C++ soit non pas du code C++ mais du code Qt. De mon point de vue, il y aura toujours besoin au minimum de wrappers pour se placer par-dessus un code C++ pur, parce que ce genre de code non événementiel (n'indiquant pas au minimum par des callbacks lorsqu'une valeur change) est non exploitable avec du QML. Et quitte à partir sur des wrappers longs à développer qui ralentiront le process de développement, je préconise carrément de coder directement du code non générique événementiel (via les signaux/slots/propriétés) axé vers Qt.
Jusque là, j'ai pu présenter plusieurs projets distincts utilisant soit QML/JS seul, soit QML/JS combiné plus ou moins efficacement à C++. Une question en rapport avec le sondage se pose : quel est l'impact des performances sur le code QML/JS/C++ ? À quel point est-ce intéressant de travailler avec une logique en C++ ?
Conceptuellement, l'aspect orienté objet de C++ me semble plus intuitif que l'OO de JavaScript, ce qui fait que je vais préférer coder ma logique en C++ plutôt qu'en JavaScript. Sauf que vu les ennuis, par moment, je me demande s'il ne vaut pas mieux faire ses classes en JavaScript et interfacer ça simplement avec les modèles QML. L'intérêt premier d'avoir le C++ à côté du QML/JS est de se forcer à faire une découpe Model/View propre. Et selon les projets, on peut clairement s'en passer, ce qui engendre en général un réel gain de temps (les applications Qt Quick 1.0 ont été développées relativement rapidement et efficacement et y intègrent bien des animations). Par contre, on ne pourra pas m'enlever de la tête que C++ est indispensable pour étendre QML quand celui-ci s'avère insuffisant. Dans le cadre d'une appli qui ferait toutes les 30ms un affichage de données de caméra, utilisez du C++ pour le timer comme pour le composant d'affichage, n'allez surtout pas utiliser un Canvas et des draws pixel par pixel en JavaScript dessus si vous ne voulez pas que les performances en soient sévèrement dégradées. Mais rien n'empêche d'utiliser C++ pour étendre QML de sorte d'utiliser ces classes C++ dans le QML.
Bref, j'en conclus de mes expériences que QML/JS est viable et sans doute bien plus performant que bien des applications utilisant HTML5/CSS3/JS embarquées dans un WebKit. J'en conclus également que dans nombre de cas où les performances nécessitent d'être minutieux, C++ est à préférer. Et rien n'empêche d'étendre par du C++ QML pour ses propres besoins et de coder la logique en JavaScript derrière pour mêler interactions utilisateur et fonctionnement de l'application elle-même. En gros, c'est très situationnel de mon point de vue, mais pas moins important : une erreur de conception mène a de sales conséquences.
Je suis très intéressé par tous les arguments que vous, lecteurs, pouvez ajouter, étant donné que j'ai beaucoup de mal à trancher et que vous avez peut-être des expériences/tests effectués à partager.
Bonne journée,
Louis
1 |
0 |
Utilisez-vous Qt Quick et le langage QML pour vos applications ?
.
Envoyé par Cyborg
