Qt Quick : des interfaces déclaratives hors norme ?

Version imprimable

12/03/2011, 15h18
dourouc05

Qt Quick : des interfaces déclaratives hors norme ?

Il y a peu, Nokia lançait Qt Quick, un nouveau module de Qt permettant de décrire des interfaces graphiques, un paradigme alors présenté comme assez nouveau. Or, une simple recherche à l'aide de Google montre bien que ces technologies ne sont pas récentes du tout, on trouve par exemple des traces de K, un langage presque ésotérique tellement il est peu connu du grand nombre actuellement, dans les années 90. Qu'est-ce qui a changé depuis lors ?

Aussi, on peut remarquer que d'autres technologies phares dans le développement applicatif telles que .NET ou Java en disposent depuis belle lurette. On peut notamment citer XAML (arrivé avec le .NET Framework 3.0) du côté .NET ou Swul pour Java. Qu'ont-ils donc de différent ? Peut-on les comparer ? Ils tentent tous d'atteindre un certain but (simplification de l'écriture de telles interfaces, possibilité de laisser des personnes compétentes dans le domaine réaliser des interfaces, pas besoin que les designers apprennent le langage utilisé pour l'application, etc.), y a-t-il au moins un qui y arrive ?

Nokia présente son QML, le langage déclaratif utilisé avec Qt Quick, comme étant un must pour toutes les applications mobiles ; Swul n'en parle pas ; XAML n'est disponible que pour le Windows Phone 7 et Symbian. Y a-t-il réellement une utilité à utiliser de telles technologies pour des applications mobiles ? Deux sociétés au moins le considèrent comme un élément majeur dans ce cas d'utilisation, mais le côté Java de la situation n'en fait même pas mention... Java en retard sur ses concurrents ? Aussi, on peut se demander ce qui arrivera à Qt sur les plateformes mobiles, malgré le récent Qt Mobility et d'autres outils comme PySide, prévus pour le développement sur mobiles : on ne peut pas développer en code natif pour Windows Phone 7, que pourra venir faire Qt et son code natif C++ ? Devra-t-il se cantonner au desktop, ce pour quoi il est historiquement prévu ? Ces projets auxiliaires vont-ils être abandonnés ?

Mais aussi d'un point de vue de l'écriture de tel code : alors que QML et Swul adoptent une syntaxe proche, un langage structuré, Microsoft a joué la carte du XML dont dérive XAML. Remarquons que seuls QML et XAML disposent d'un éditeur visuel. Quels sont les avantages de telle ou telle option ? Le XML, auparavant exclusivement plébiscité, commence à voir son horizon se ternir, avec notamment l'arrivée de concurrents comme le YAML, moins redondants à l'écriture, plus légers. Possède-t-il un avantage dans cette utilisation ? Ou bien ce choix ne se base-t-il que sur une mode ?
17/03/2011, 09h15
buzzkaido

Je n'ai encore jamais essayé QtQuick, mais je suis un fan de Qt, qui marche très très très bien....

Du coup, je me pose la question du QML pour le web.

Imaginons quelque chose comme un plugin du navigateur ou carrément une application "desktop" (Qt, donc multi-plateforme, fixe et mobile) qui se connecte à un serveur d'application qui délivre des application écrites en QML.

Ce ne serait pas un moyen d'écrire des applications comme les "RIA" d'aujourd'hui mais en remplaçant le HTML/CSS/Javascript par des technos Qt/QML ?
17/03/2011, 10h01
spidermario

Citation:

Envoyé par dourouc05

Aussi, on peut remarquer que d'autres technologies phares dans le développement applicatif telles que .NET ou Java en disposent depuis belle lurette. On peut notamment citer XAML (arrivé avec le .NET Framework 3.0) du côté .NET ou Swul pour Java. Qu'ont-ils donc de différent ? Peut-on les comparer ? Ils tentent tous d'atteindre un certain but (simplification de l'écriture de telles interfaces, possibilité de laisser des personnes compétentes dans le domaine réaliser des interfaces, pas besoin que les designers apprennent le langage utilisé pour l'application, etc.), y a-t-il au moins un qui y arrive ?

Si on considère que XAML est comparable à QML, alors le XML produit par Qt Designer et consommé par uic l’est tout autant, non ? Lui aussi permet de laisser des designers concevoir les interfaces.
17/03/2011, 10h41
barmic
C'est intéressant parce qu'il y a quelques semaines j'ai voulu m'y mettre et je me suis ravisé. Deux choses m'ont "calmées" :
- premièrement je ne suis pas un grand fan de Qt, l'utiliser en python par exemple ça doit aller, mais en C++ je trouve que c'est très contraignant (chaîne de compilation complexe, ajout fait au C++ pas très C++,...), c'est là un avis personnel qui n'est, il me semble pas partagé par tous ;
- la documentation et soit mal foutue soit je n'ai pas su la cherché, toutes les présentations se contentent montrer du QML/QtQuick sans connexion avec du C++ à tel point que je me suis demandé si c'était possible. L'énorme majorité ne parle que d'embarqué.
Citation:

Envoyé par buzzkaido

Imaginons quelque chose comme un plugin du navigateur ou carrément une application "desktop" (Qt, donc multi-plateforme, fixe et mobile) qui se connecte à un serveur d'application qui délivre des application écrites en QML.

La plupart des framework web palie se problème en effectuant des conversions de leur format de représentation à eux vers HTML/XHTML/Javascript(si besoin), ça permet d'être compatible avec tout et de ne pas avoir à gérer autant de plugins que de navigateurs et c'est moins contraignant pour l'utilisateur.
17/03/2011, 11h29
gillai

Citation:

Envoyé par barmic

la documentation et soit mal foutue soit je n'ai pas su la cherché, toutes les présentations se contentent montrer du QML/QtQuick sans connexion avec du C++ à tel point que je me suis demandé si c'était possible. L'énorme majorité ne parle que d'embarqué.

Quelle genre de présentation ?

http://qt.developpez.com/doc/4.7/qpushbutton.html

http://qt.developpez.com/doc/4.7/classes.html
17/03/2011, 11h30
Makano

La documentation est effet un peu mal foutu mais en cherchant bien on tombe sur les bonnes choses => qml-extending-tutorial. Après pour la chaîne de compilation faut pas pousser non plus, nokia fournit tous les outils pour ne pas avoir à s'en préoccuper et ça marche plutôt bien, ça reste du même niveau qu'un cmake.

Personnellement ça fait quelques semaines que j'en fait et je suis encore mitigé sur la techno. Certes elle répond bien à la simplicité de création d'une interface, mais ça reste assez jeunes encore comme technologie. Dès qu'on sort un peu des sentiers battus, ça devient très vite la galère et faut bien maîtriser complètement QML et son interaction avec le C++, on est loin du domaine du designer quand même. Avec le plugin d'export photoshop par contre on simplifie le lien dev/designer mais le qml reste quand même un outil pour le dev.
17/03/2011, 12h20
gorgonite
dans la catégorie des trucs dans ce genre qui prétendaient révolutionner le monde, et qui n'ont au final qu'imposer à leurs utilisateurs un dialecte "sympa" une fois qu'on a passé assez de temps à comprendre sa mécanique... tu as oublié de citer
- le concurrent, Gtk/Glade et son XML. je ne connais personne s'en servant, mais après tout, ce n'est pas comme si ça intéressait quelqu'un :aie:
- le très controversé XUL/XPCom/XBF de Mozilla, qui aurait pu être sympa si seulement tout ne changeait pas à chaque version majeure, que les projets "presque prêts" ne restaient pas dans cet état depuis la version 1.0 (oui oui, Python et Firefox c'est possible... si l'on veut être le seul à se servir de ses extensions :aie:)
- JavaFX, là encore, je ne connais aucun gros projets s'en servant... (mais bon Java et moi, ça fait au moins 2, le seul mérite de la plateforme étant de servir à Scala et de faire croire à un développeur desktop qu'il a le niveau pour aller s'attaquer au marché de l'embarqué :roll:)
17/03/2011, 12h42
barmic
[quote=hivenz;5847601]Quelle genre de présentation ?

http://qt.developpez.com/doc/4.7/qpushbutton.html

http://qt.developpez.com/doc/4.7/classes.html
Je me suis mal exprimé. Je voulais dire tutoriel ou guide, quelque chose qui explique comment on fait sans aller justement lire la description de chaque classe.

@Makano > Merci du coup je regarderais de plus près.
Citation:
Envoyé par gorgonite

dans la catégorie des trucs dans ce genre qui prétendaient révolutionner le monde, et qui n'ont au final qu'imposer à leurs utilisateurs un dialecte "sympa" une fois qu'on a passé assez de temps à comprendre sa mécanique... tu as oublié de citer

le concurrent, Gtk/Glade et son XML. je ne connais personne s'en servant, mais après tout, ce n'est pas comme si ça intéressait quelqu'un :aie:
J'ai vu plusieurs logiciels s'en servir, même si je ne pourrais pas te donner leur nom. glade si je ne me trompe pas ne faisait pas vraiment partie du projet Gtk, maintenant il y a Gtk builder qui fait partie intégrante du projet Gtk.
17/03/2011, 12h59
highleaf

Je suis justement en train de me "former" sur PySide/QML et je peux en tirer quelques remarques :

1 - Croire que des designers vont s'en sortir avec le QML, j'ai des doutes, c'est assez complexe quand même, il faut comprendre la logique déclarative. QML et le modèle applicatif sont fortement liés.

2 - On sent la mode du développement web arriver sur le desktop et ce n'est pas nouveau (Appcelerator Titanium), mais n'est-il pas plus facile d'embarquer un mini serveur web et faire son application avec du html/javascript.

3 - Une application en full QML j'y crois pas : il faut toujours de la donnée, soit elle vient du web soit elle vient d'une base ou fichier, dans tout les cas, il faut un langage applicatif derrière, pour moi c'est Python. Le QML est pauvre en modules : pas d'accès à des bases de données, pas de json, pas de parser rss ou des trucs dans le genre.

4 - Les échanges entre la couche applicative et la vue ne sont pas des plus simples, pas tellement de docs sur l'implémentation des modèles.

5 - Il y a beaucoup de docs mais pour le C++, pas grand chose sur PySide, en ce qui concerne par exemple, l'implémentation des modèles. Je trouve cela très complexe quand on compare cela avec un framework web et les échanges qu'il peut y avoir avec le javascript, le JSON simplifie bien les choses.

6 - Je suis agréablement surpris de la performance d'affichage.

7 - Enfin mettre à disposition une technologie similaire à celle du web sur le desktop, je trouve qu'il vaut mieux partir directement avec un framework web embarqué.

En gros, je vais abandonner un peu pour le moment car je passe trop de temps à calquer le C++ en Python. Je perds trop de temps pour être efficace.
Je vais attendre qu'il y ait de la doc supplémentaire et des modules QML plus intéressants. Le top serait l'intégration de PySide dans QtCreator. C'est dingue de proposer un javascript like pour l'interface et rester avec du C++. Est-ce vraiment justifié du C++ pour ce genre d'applications ? Je doute que l'on fasse un CRM en QML...
17/03/2011, 12h59
yan

LA doc QML est certe pauvre par rapport au reste mais il y as pas mal de chose si tu regarde bien les exemple :
http://qt.developpez.com/doc/latest/.../#c-extensions

En gros c'est trés proche de QtScript pour le coeur et des GraphicsItem pour l'affichage. Qml peux appeler les slot et les méthode taggé INVOKABLE et les properties d'un QObject. Il exploite les metadata comme QWebKit.

Pour te connecter à un signal, y as une syntaxe mais la j'ai un trou noire :aie:

Ensuite il te faut enregistrer ton QObject au context QML.
17/03/2011, 13h14
highleaf

Bien oui c'est ce que je dis c'est de la doc pour C++.

Quand tu te formes à Qt, ce sont justement ces notions dont tu parles qui ne sont pas documentées pour Python et pas forcément évidentes pour un nouveau. Bref en gros pour afficher une liste de 10 éléments dans une liste QML, faut un modèle comme QAbstractListModel, une classe pour créer les objets à passer à la QML (Qobject) et un ensemble de slots/signaux pour échanger les données entre cette vue et le modèle, et bien c'est justement tout cela que je trouve complexe dans cette technologie pour afficher 10 éléments. Et éventuellement d'autres classes si tu veux intercepter un signal particulier pour te synchroniser avec la vue. Avec un framework web, tu passes tes données en JSON et c'est réglé pour au final le même résultat avec 5 fois moins de code.
17/03/2011, 13h33
Makano

Je suis tassez d'accord avec highleaf pour le coté gestion du modèle. Dès que t'as un truc qui n'est pas une liste faut tout de suite sortir le C++ et très bien maitriser QML pour intégrer correctement ton modèle. Et de ce coté la doc aide pas vraiment.

Mais j'ai quand même envie de croire que c'est la jeunesse du QML qui veut ça.
17/03/2011, 13h49
yostane

QML me fait un peu penser à JavaFX. JavaFX était au début très prometteur mais au final il m'a vraiment déçu. J'espere que QML ne subira pas le même sort.
17/03/2011, 14h45
highleaf

En plus j'aurais préféré générer les vues directement du côté de Python. Dans tous les cas, pour que les dev se mettent au QML après ce qu'il s'est passé autour de Nokia, ils doivent faire un gros effort sur la doc et les exemples. Mais je ne pense pas qu'il y aura une grosse mode QML.
17/03/2011, 14h59
yan

Citation:

Envoyé par highleaf

Bien oui c'est ce que je dis c'est de la doc pour C++.

Ce n'était pas une réponse à ton poste :aie:

On ne peut pas créé de QObject avec pyside? definir des signaux? des property, .. ?
http://developer.qt.nokia.com/wiki/P...25c37df1efd5c2
17/03/2011, 15h42
highleaf

Citation:

Envoyé par yan

Ce n'était pas une réponse à ton poste :aie:

On ne peut pas créé de QObject avec pyside? definir des signaux? des property, .. ?
http://developer.qt.nokia.com/wiki/P...25c37df1efd5c2

Je ne crois pas que tu aies lu mon post. Je ne dis pas qu'on ne peut pas le faire, je dis seulement qu'on ne sait pas comment le faire...
17/03/2011, 16h01
yan

Citation:

Envoyé par highleaf

je dis seulement qu'on ne sait pas comment le faire...

j'aurais comme en C++...
Je connais trés peux python mais il semblais que tu pouvais te baser de la doc C++ pour développer en python.
Je vais essayer pour voir. Depuis le temps que j'entend parler de python, faut bien essayer.
17/03/2011, 21h30
dscreve

Et interface builder ?

Et sinon, dans le genre impasse totale, il y a interface builder qui résoud tous les problèmes cités....Cocoa est le seul framework qui fournit des classes de contrôleurs pour implémenter du mvc et empêche pratiquement toute autre forme d'ecriture bancale....
Dans cocoa, on peut décrire son modèle de donnes graphiquement, le câbler à la souris sur sur l'ohm, elle même dessinée entièrement a la souris....on n'ecrit plus que du code métier....

Face a cocoa, Qt s'en sort un peu, Xaml un peu moins bien, et alors java est complètement a la rue.
28/03/2011, 11h43
Khertan

QML, ca peut être pas mal dans le futur, mais actuellement, ce n'est pas prêt pour le commun des dev.

Exemple typique. Un bouton, il vous faudra prévoir son comportement, ainsi que le feedback qui doit etre rendu a l'utilisateur lors d'un clic ou d'un survol, la tooltip qui va avec, et géré le shortcut ....

Pour revenir la dessus ""3 - Une application en full QML j'y crois pas : il faut toujours de la donnée, soit elle vient du web soit elle vient d'une base ou fichier, dans tout les cas, il faut un langage applicatif derrière, pour moi c'est Python. Le QML est pauvre en modules : pas d'accès à des bases de données, pas de json, pas de parser rss ou des trucs dans le genre."" : il y a un exemple de lecteur rss en full qml, un exemple pauvre de twitter avec du json.

Sinon question rapidité, je n'y crois pas non plus, encore une surcouche. D'ailleurs, j'avais commencé à refaire l'interface de mon client twitter pour n900 en QML mais j'ai laché l'affaire, des que l'on veut faire des interfaces un peu complexe avec autre chose que des tailles fixes, exemple une liste de tweet (donc size row variable) cela recalcul la taille en permanence et saccade sur un n900.
28/03/2011, 12h28
gbdivers

Citation:

Exemple typique. Un bouton, il vous faudra prévoir son comportement, ainsi que le feedback qui doit etre rendu a l'utilisateur lors d'un clic ou d'un survol, la tooltip qui va avec, et géré le shortcut....

Dans la prochaine version, Qt Quick devrait intégrer Qt Component, un ensemble d'éléments de base (boutons, zone de texte, etc.) pour le QML

Citation:

Sinon question rapidité, je n'y crois pas non plus, encore une surcouche. D'ailleurs, j'avais commencé à refaire l'interface de mon client twitter pour n900 en QML mais j'ai laché l'affaire, des que l'on veut faire des interfaces un peu complexe avec autre chose que des tailles fixes, exemple une liste de tweet (donc size row variable) cela recalcul la taille en permanence et saccade sur un n900.

Le problème n'est pas réellement la rapidité du QML. Une IHM passe plus de temps à rien faire et à attendre un évènement utilisateur qu'autre chose. Il faut juste bien concevoir son application pour répartir ce qu'il faut du côté du QML et ce qu'il faut du côté de Qt. Un exemple typique, si tu essaies de calculer toi même les dimensions de tes objets QML dans le script, ça va ramer. Si par contre, tu utilises les layouts, le calcul des dimensions et positions sera aussi rapide qu'en C++ (puisque le QML appellera les classes QLayout correspondantes, comme on le ferait aussi en C++). Idem si tu crées des animations en QML au lieu d'utiliser des QAnimations, etc.

Si tu débutes en QML, il est possible que ton code pour ta liste de tweet ne soit pas "optimisé" (si tu veux je peux te donner du code C++ qui ramera aussi... il ne faudrait pas en conclure que le C++ est lent)

Signé : quelqu'un qui n'a pas accroché non plus avec le QML (donc qui n'est pas là pour le défendre particulièrement)
08/06/2011, 14h43
Khertan

Citation:

Envoyé par gbdivers

Le problème n'est pas réellement la rapidité du QML

Sur un mobile, si tout de même. 8s pour charger la première fenêtre de l'appli c'est trop (Nokia n900 ... 600Mhz ... c'est pas ce qui se fait de plus low cost).

Citation:

Envoyé par gbdivers

Si tu débutes en QML, il est possible que ton code pour ta liste de tweet ne soit pas "optimisé" (si tu veux je peux te donner du code C++ qui ramera aussi... il ne faudrait pas en conclure que le C++ est lent)

Quelques semaines plus tard ... :

Bon les composants, on attends toujours ... surtout entre les composants pour les tablettes, Handset UX et ceux de Nokia qui n'auront probablement pas d'api commune dans un premier temps.

Sinon concernant ma liste de tweets, le problème viens du calculs des dimensions du textes et du positionnement relatif des éléments. En effet, ils sont recalculé a chaque raffraichissement, défilement, ... ce qui n'est pas le cas avec les QWidgets, car mon paint event à un cache sur les tailles calculé. J'ai donc la raison.

Cependant, QML est toujours loin d'atteindre le niveau des QWidgets au niveau des fonctionnalités. Et le probleme est qu'il ne semble pas prévu de "themer" les QWidget sur Meego Handset UX, ce qui les rends inutilisable.

Exemple typique, il n'est pas possible de faire de la coloration syntaxique dans un TextEdit QML. Certes pour le moment, car certaine personne de #qt-qml tendent à dire que cela sera dispo dans QtQuick 2.0.