J'avais testé QT Creator il y a quelques temps pour un projet professionnel qui nécessitait éventuellement un client graphique. J'avais trouvé ça pratique pour faire un "canevas" de mon application ; par contre pour le contenu vraiment dynamique (d'un point de vue contenu, pas d'un point de vue animation) ce n'était pas du tout adapté. Qu'en est-il de QML ?
Le jour où tu veux ajouter un nouveau mode de fonctionnement de ton application qui présente un contenu complètement différent, ça évolue bien QML ? Il suffit de faire une fabrique et d'instancier le nouveau contenu au lieu de l'ancien ? Exemple : je fais un browser de fichiers musicaux, ma première version permet de naviguer dans mes fichiers MP3 et d'afficher les tags ; puis un jour je décide de gérer aussi les OGG (tout en affichant les tags spécifiques) et je veux également proposer une interface de modification des tags et un lecteur audio. Ca se fait bien ? (je parle pas d'ajouter un bouton dans la barre d'outils, hein, je parle d'instancier un "widget" mp3 ou ogg ou je sais pas quoi avec une logique potentiellement tout à fait différente).
Je suis relativement sceptique sur les interfaces déclaratives (sauf pour des applications relativement simples). Ok on peut scripter l'interface en ECMAScript et faire le reste en C++. Mais un code dont l'intelligence est éclatée dans différents languages et différentes logiques est difficile à maintenir. Donc pour moi l'idée "on fait du ECMAScript et si ça on atteint les limites on code ça en C++" c'est une mauvaise idée. A la limite si on décide "telle intelligence en ECMA, et telle autre en C++" ça a une logique...
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
# Programmation d'interfaces graphiques déclaratives ?
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal QML: le futur des interfaces graphiques. Évalué à 1.
Le jour où tu veux ajouter un nouveau mode de fonctionnement de ton application qui présente un contenu complètement différent, ça évolue bien QML ? Il suffit de faire une fabrique et d'instancier le nouveau contenu au lieu de l'ancien ? Exemple : je fais un browser de fichiers musicaux, ma première version permet de naviguer dans mes fichiers MP3 et d'afficher les tags ; puis un jour je décide de gérer aussi les OGG (tout en affichant les tags spécifiques) et je veux également proposer une interface de modification des tags et un lecteur audio. Ca se fait bien ? (je parle pas d'ajouter un bouton dans la barre d'outils, hein, je parle d'instancier un "widget" mp3 ou ogg ou je sais pas quoi avec une logique potentiellement tout à fait différente).
Je suis relativement sceptique sur les interfaces déclaratives (sauf pour des applications relativement simples). Ok on peut scripter l'interface en ECMAScript et faire le reste en C++. Mais un code dont l'intelligence est éclatée dans différents languages et différentes logiques est difficile à maintenir. Donc pour moi l'idée "on fait du ECMAScript et si ça on atteint les limites on code ça en C++" c'est une mauvaise idée. A la limite si on décide "telle intelligence en ECMA, et telle autre en C++" ça a une logique...
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo