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 !

Qt Quick : des interfaces déclaratives hors norme ? Pourquoi ne sont-elles pas encore répandues ?

Le , par dourouc05

0PARTAGES

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

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de spidermario
Membre éprouvé https://www.developpez.com
Le 17/03/2011 à 10:01
Citation Envoyé par dourouc05 Voir le message
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.
2  0 
Avatar de barmic
Membre actif https://www.developpez.com
Le 17/03/2011 à 10:41
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.
2  0 
Avatar de buzzkaido
Membre éclairé https://www.developpez.com
Le 17/03/2011 à 9:15
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 ?
1  0 
Avatar de gorgonite
Rédacteur/Modérateur https://www.developpez.com
Le 17/03/2011 à 12:20
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
  • 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 )
  • 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é )
1  0 
Avatar de gbdivers
Inactif https://www.developpez.com
Le 28/03/2011 à 12:28
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

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)
1  0 
Avatar de gillai
Membre averti https://www.developpez.com
Le 17/03/2011 à 11:29
Citation Envoyé par barmic Voir le message
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
0  0 
Avatar de Makano
Candidat au Club https://www.developpez.com
Le 17/03/2011 à 11:30
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.
0  0 
Avatar de barmic
Membre actif https://www.developpez.com
Le 17/03/2011 à 12:42
[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  Voir le message
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

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.
0  0 
Avatar de highleaf
Membre à l'essai https://www.developpez.com
Le 17/03/2011 à 12:59
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...
0  0 
Avatar de yan
Rédacteur https://www.developpez.com
Le 17/03/2011 à 12:59
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

Ensuite il te faut enregistrer ton QObject au context QML.
0  0