Un vent de migration : de nombreuses applications GTK passent à Qt

Un vent de migration : de nombreuses applications GTK passent à Qt

Ces derniers mois, trois applications GTK ainsi qu'un environnement de bureau sont passés au framework Qt :

• GCompris, une application éducative pour enfants, structurée en activités ;
• Subsurface, une application de suivis de plongée, créée par Linus Torvalds ;
• WireShark, logiciel d'analyse de paquets réseaux ;
• LXDE, bureau X léger, qui collabore activement avec razor-qt en abandonnant GTK.

Ces trois applications ont un point commun : elles sont multiplateformes. C'est d'ailleurs là la plainte des développeurs contre GTK. En effet, ce framework possède des soucis de rendu sous Windows et OS X. De plus, le support des appareils mobiles (téléphones et tablettes) n'est pas simple à effectuer lors de l'utilisation de GTK.

Pour les développeurs de GCompris, le langage déclaratif Qt Quick est un outil appréciable pour la réalisation des interfaces et même de la logique de l'application (en JavaScript). Le manque de support des plateformes mobiles s'est aussi révélé compromettant pour la suite du projet.

Les développeurs de Subsurface – dont Linus Torvalds, qui n'hésite pourtant pas à crier son amour pour le C++ – ont présenté une conférence à l'occasion du Linux.conf.au 2014, où Dirk Hohndel explique les raisons qui l'ont poussé à passer à Qt.

Du côté de Wireshark, le plus gros problème était l'intégration catastrophique de GTK avec l'interface d'OS X.

Bien entendu, ce changement ne se fait pas du jour au lendemain. Il est bien souvent nécessaire de recoder le cœur de l'application. Ce genre d'opération pourrait prendre des années, comme celle qui a mené Netscape à l'extinction.

Toutefois, chacun de ces projets avance à bon train, comme vous pourrez le constater sur leur dépôt. Ils considèrent tous ce changement comme bénéfique. GCompris proposera d'ailleurs des activités pour le prochain Google Summer of Code. Si le cœur vous en dit, n'hésitez plus à apprendre Qt ou Qt Quick et venir aider un projet open source !

Sources : Blog Wireshark, Blog LXDE, GCompris

Voir aussi : la vidéo de la conférence de Dirk Hohndel.

Et vous ?

:fleche: Quel framework préférez-vous ?
:fleche: Quelles difficultés rencontrez-vous lors de la migration de vos projets ?
:fleche: Comment envisageriez-vous une telle migration si vous deviez la faire ?

:salut:

Je suis de plus ou moins loin l'évolution de LxQt (le nom de LXDE en version Qt) que l'on retrouve déjà dans certaines distributions en version "test", et j'attends avec impatience que le projet soit plus mûr.

Pour ma part, j'utilise Qt (enfin PyQt) depuis quelques temps déjà et il faut bien dire que ce framework offre beaucoup d'avantages, est très complet et très mature. Je trouve donc tout à fait normal que des applications GTK+ passent peu à peu à Qt d'une manière globale.

Mais l'arrivée Qt Quick va, selon moi, encore boulverser bien plus le monde du framework.

En effet, sa simplicité, sa portabilité (y compris sur des appareils mobiles) et sa constante amélioration vont en faire une solution quasi inévitable pour beaucoup de développeurs. Je pense même que la migration ne se limitera pas aux applications écrites en GTK ou autre, mais touchera aussi et logiquement les applications écrites en pur Qt (QtGui, QtWidgets, ...). En tout cas c'est mon cas.

Pour ma part, je reprends actuellement un projet initialement écrit en PyQt pour le transcrire en "PyQuick". Bien que le projet en lui-même ne soit pas très compliqué, cela demande beaucoup de travail car les outils offerts par Qt Quick me permettent, petits à petits, de refaire les GUI de mon application mais aussi d'aller au-delà et ainsi de réduire la proportion de code Python. L'intêret :

• une éventuelle portabilité vers du C++ plus aisée à faire si cela venait à être nécessaire ;
• quelques tests très succints me poussent à croire que Qt Quick et en particulier le langage qu'il supporte (QML) est plus performant que Python

Citation:

---

Envoyé par LittleWhite

Un vent de migration : de nombreuses applications GTK passent à Qt

---

Il n'y en a que 4 c'est pas encore un avis de tempête...

Citation:

---

Envoyé par LittleWhite

LXDE, bureau X léger, qui collabore activement avec razor-qt en abandonnant GTK.

---

S'ils pouvaient en profiter pour faire tourner ça sous windows ou mac osx ça serait super :coucou:

Citation:

---

Envoyé par valkirys

Il n'y en a que 4 c'est pas encore un avis de tempête...

---

T'as aussi Ubuntu.

Citation:

---

Envoyé par LittleWhite

Les développeurs de Subsurface – dont Linus Torvalds, qui n'hésite pourtant pas à crier son amour pour le C++

---

Chaque fois que je vois une news où l'on attribue des citations à ce type, je le déteste plus. J'adore Linux, j'aime vraiment bosser avec, mais je trouve ce type parfaitement haïssable.

Etant développeur Qt et n'ayant jamais compris quels pouvaient être les avantages de Gtk, je trouve ça très bien. De la même façon que je trouve très bien que les applis qui abandonnent la surcouche KDE pour s'appuyer directement sur Qt, à part pour certaines choses bien précises, la surcouche KDE n'apporte rien et Qt a l'avantage de rendre assez simple le portage sur plusieurs plateformes.

En revanche je m’interroge sur la remarque dans l'article:

Citation:

---

Envoyé par LittleWhite

Les développeurs de Subsurface – dont Linus Torvalds, qui n'hésite pourtant pas à crier son amour pour le C++

---

Qt c'est du C++ !! Maintenant avec QtQuick on peut faire des applications simples sans faire du code C++ mais ça reste encore assez limité, la couche métier reste en C++ en général (ne serait-ce que pour réutiliser l'existant ou se connecter à d'autres bibliothèques)

@olreak: que Linus crie son amour pour le C++ est ironique. il suffit de cliquer sur le lien pour s'en rendre compte. De plus il préfére les langages bas niveau, tout le contraire de ce que permet QtQuick.

En même temps quand on voit la tronche d'un code Gtk... C'est absolument horrible, déjà l'idée d'avoir voulu faire un toolkit en C est à mon avis une très mauvaise idée. Avec l'absence de namespace et de techniques modernes on est obligé de bricoler. Et déclarer une simple "classe GObject" nécessite une tonne de code.

Citation:

---

Envoyé par olreak

Maintenant avec QtQuick on peut faire des applications simples sans faire du code C++

---

Et ça c'est vraiment le top. Et j'ajouterai même sans faire du code Python pour les Pythoniens utilisant PyQt.

Citation:

---

Envoyé par olreak

mais ça reste encore assez limité, la couche métier reste en C++ en général (ne serait-ce que pour réutiliser l'existant ou se connecter à d'autres bibliothèques)

---

En ce qui concerne l'existant et la connexion à d'autres biblio je suis tout à fait d'accord avec toi, mais Qt Quick devient de plus en plus "autonome". Il suffit de voir l'évolution entre la version de Qt 5.0 et celle de Qt 5.2... et je ne parle pas de celle entre la version Qt 4.8 et Qt 5.2, car là c'est limite passer de GTK à Qt :mrgreen:

Je réalise une GMAO simpliste pour mon taf et aujourd'hui la seule chose essentielle qui me manque pour faire tourner l'appli en pur Qt Quick (cad sans passer par Python) est la gestion d'une base de données PostgreSQL.

Ensuite se pose le problème de la distribution (standalone ???), mais de toutes façons c'est déjà actuellement un problème. Je n'ai pas encore cherché à trouver les dépendances pour faire tourner qmlscene en standalone.

Bref, Qt Quick c'est juste formidable ... il ne manque plus qu'il soit réellement "natif" sur les appareils mobiles, j'entends par là que l'on ne soit pas obligé de passer par une couche java, même si aujourd'hui Qt Creator fait tout à notre place et de manière quasi transparente.
En gros, quel bonheur ça serait que mon Galaxy S3 puisse directement lire mes code QML :mrgreen:

Tant que des projets comme Gnome et Xfce continuent sous GTK, il n'y aura pas de vague d'adoption pour Qt ;)
Après je comprends que certains préfèrent developper avec un IDE comme QtCreator que via les outils de Gtk :)

Citation:

---

Envoyé par imikado

Tant que des projets comme Gnome et Xfce continuent sous GTK, il n'y aura pas de vague d'adoption pour Qt ;)

---

Tu peux développer ton argument car là je vosi pas trop où tu veux en venir...

Citation:

---

Envoyé par imikado

Après je comprends que certains préfèrent developper avec un IDE comme QtCreator que via les outils de Gtk :)

---

Tu crois franchement que les developpeurs travaillent avec un langage ou un framework parce que l'IDE phare est mieux ??? Très sincèrement si c'est le cas, alors là on touche le fond.

Pour moi un framework ou un langage est choisi par rapport à ce qu'il permet de faire, comment il le permet et et les connaissances que l'on peut avoir sur le langage ou la biblio en queston. Je pense que Gnome et XFce ont été développés en GTK car à l'instant T c'était ce framework qui répondait au mieux aux attentes des développeurs. Tu proposes à ces mêmes personnes le même boulot avec les mêmes connaissances de bases aujourd'hui :fleche: je mets ma main à couper qu'ils choisissent Qt Quick.

Exemple très simple de ce que j'avance : Le développement d'appli mobile. Sauf erreur de ma part, à ce jour seul Java permet de faire des applis mobiles sans passer par je ne sais quel tour de magie : :fleche: faut complètement être taré pour coder en Java :mrgreen:, alors qu'une appli Qt Quick est si simple à faire. :mouarf:

Je suis bien content de cette nouvelle, cela montre la popularité du framework.
Par contre, et ce qui me fait le plus peur, c'est que l'on mise de plus en plus sur QtQuick/QML/Javascript et que l'on met de côté la partie C++.
Cela me donne l'impression que d'ici quelques années, on ne pourra plus du tout développer en C++ avec Qt, mais je peux me tromper.

++

Citation:

---

Envoyé par charlespf

Je suis bien content de cette nouvelle, cela montre la popularité du framework.
Par contre, et ce qui me fait le plus peur, c'est que l'on mise de plus en plus sur QtQuick/QML/Javascript et que l'on met de côté la partie C++.
Cela me donne l'impression que d'ici quelques années, on ne pourra plus du tout développer en C++ avec Qt.

++

---

:salut:

En fait cela évolue avec son temps, et je ne pense pas que le temps où Qt et C++ soit incompatible soit prêt d'arriver. Il y a encore du chemin à faire pour surpasser les performances du C++ notamment sur des grosses applications.

Il est clair que dans le cas de ma petite appli, même si j'avais correctement maitrisé le C++, cela n'aurait pas été différent : je maximiserai le QML. Pourquoi faire compliqué lorsque l'on peut faire simple. Mais ça reste une appli très basique.

Pour un jeux vidéo par exemple ça pourrait être plus hardu, quoique ... peut être pas ;)

Citation:

---

Envoyé par Jiyuu

Tu peux développer ton argument car là je vosi pas trop où tu veux en venir...

---

L'idée : on essaie généralement d'utiliser des applications et environnement de bureau utilisant les mêmes librairie graphique:
Si on utilise du Gnome/xfce, on evoluera en gtk avec des applications comme nautilus/thunar, leafpad/gedit, rapidsvn...
Alors que si on choisi kde/razorQt on aura plutot dolphin, kate et ksvn pour le gestionnaire de sources
Donc si on a les deux derniers environnement de bureau gtk qui migrent vers Qt, là on aura une "vague de migration" ;)

Citation:

---

Envoyé par Jiyuu

Tu crois franchement que les developpeurs travaillent avec un langage ou un framework parce que l'IDE phare est mieux ??? Très sincèrement si c'est le cas, alors là on touche le fond.

---

IL y a quelques années, j'avais besoin de développer une petite application de gestion de comptes, je n'avais d'à priori sur aucun des deux, mais j'ai choisi à l'époque Qt car il m'était plus facile de developper avec QtCreator qu'avec anjuta and co
Donc désolé, mais oui l'environnement de developpement plus ou moins confortable joue sur le taux d'adoption d'une bibliothèque/language de developpement, surtout pour les nouveaux développeurs d'application ;)

Et je ne suis pas le seul à le penser : Dirk Hohndel d'Intel

Citation:

---

Envoyé par Dirk Hohndel

Dirk also found the Qt Creator IDE to be incredibly good

---

source: http://www.phoronix.com/scan.php?pag...tem&px=MTU2ODM

Citation:

---

Envoyé par Jiyuu

:salut:

En fait cela évolue avec son temps, et je ne pense pas que le temps où Qt et C++ soit incompatible soit prêt d'arriver. Il y a encore du chemin à faire pour surpasser les performances du C++ notamment sur des grosses applications.

Il est clair que dans le cas de ma petite appli, même si j'avais correctement maitrisé le C++, cela n'aurait pas été différent : je maximiserai le QML. Pourquoi faire compliqué lorsque l'on peut faire simple. Mais ça reste une appli très basique.

Pour un jeux vidéo par exemple ça pourrait être plus hardu, quoique ... peut être pas ;)

---

OK :mrgreen:. Chacun aura son point de vue sur cette question. J'utilise C++ depuis 10 ans et Qt depuis sa version 3, pour moi il sera plus simple de partir sur une application C++.
Par contre, il est vrai que si cette application devait être utilisée sur des plateformes mobiles, je commencerai à regarder du côté de QML/QtQuick, ne serait--ce que pour la portabilité sur ces plateformes.

++

:salut:

A cette liste, je rajouterai le logiciel le plus populaire d'Edition Video sous Linux : Openshot Video Editor

Le portage est en cours vers Qt 5 entre autre (ce n'est pas le seul chose en cours , Plus d'info sur le blog officiel ou sur mon blog). A cette occasion, il ne se limitera plus à Linux mais sera aussi le nouveau fleuron du libre multiplateforme (au même titre que Firefox, Gimp, Libreoffice,...) pour l'Edition Video sous Windows et Mac OSX. :mouarf:

Pour ma part, deux points importants font que l'on assite à cette evolution : le passage à Qt 5 (surtout la suppression de la crainte que les dev avaient quand Qt 3 est passé à Qt 4) et Qt Quick qui devient de plus en plus fonctionnel et interressant.

Voila mes 2 cents sur la question. :coucou:

il me semble que beaucoup oublie que Qt Quick est un système permettant de faire une conv C++ puis en code binaire
Qt Quick n'est pas un langage mais une surcouche facilitant le codage

après j'aime utiliser Qt mais les projets ou j'en ais besoin sont rare pour moi ^^

Citation:

---

Envoyé par TiranusKBX

il me semble que beaucoup oublie que QT Quick est un système permettant de faire une conv C++ puis en code binaire
QT Quick n'est pas un langage mais une surcouche facilitant le codage

---

Qt Quick n'est pas vraiment une surcouche, c'est carrément un framework à part entière. Il est principalement basé sur le langage QML lui-même se reposant beaucoup sur Javascript.

Je pense qu'il y a un gros avantage à cela (même si je ne l'ai pas encore testé) : il doit très certainement être assez simple d'utiliser des librairies JS pour compléter les fonctionnalités de QML (édition de fichier ODF, PDF, ...)

Personnellement, quand je parle de Qt, j'ai plus l'impression de parler d'un langage différent qui intègre le C++ comme sous-ensemble ( de la même façon que le C++ intègre le C comme un sous-ensemble, et à l'origine "compilait" un source en langage C via cfront, qui était ensuite définitivement compilé, de la même façon que Qt "compile" en C++ via mok, si je me souviens bien ) que comme un simple framework.

Donc, que Linus aime Qt et pas C++ ne me surprend pas ( pour garder une vision au ras des paquerettes d'un mail sorti du contexte d'une -- voire plusieurs -- discussion sur une mailing list ).

A part ça, tant mieux pour Qt si ça marche. Selon moi, utiliser du C pour gérer des IHM n'est pas vraiment optimal, entres autres à cause du manque de gestion automatisée de la mémoire: malloc/free, ou leurs équivalents bibliothécaires, ça va un temps, mais c'est quand même vachement error-prone.
Ceci dit, j'ai quand même envie de m'inquiéter du manque d'alternatives. A part wxWidgets et GTK, il n'y a pas grand chose d'autre qui soit exploitable à la fois sous linux et windows. Enfin bon, la situation n'a pas vraiment changé de ce point de vue, et ce n'est pas près de s'arranger.

Par rapport au GTK et aux appli qui l'abandonnent, je suppose également que c'est lié au fait que l'on demande au toolkits graphiques de faire de plus en plus de choses, y compris non liées aux contrôles d'une fenêtre. GTK s'enrichissant en conséquence, et le C étant, selon moi, plus complexe à maintenir que du C++ ( grâce, entres autres, à la RAII, aux exceptions et au modèle objet plus propre qu'en utilisant glib ) le code se complexifiant, autant utiliser Qt qui me semble plus maintenable.
A ce sujet, il semble qu'il soit possible d'avoir des tests unitaires d'IHM avec Qt (jamais testé, je viens juste de le découvrir en fait), est-ce possible avec GTK? Sinon, c'est tout de même un argument fort contre GTK.

Et encore, ce n'est que des applications libres (open source...) donc avec une cetaine visibilité.
Car dans un milieu un temps soit peu professionnel/industriel (dont les outils de dev sont rarement divulgués), il me semble que la question ne se pose même plus si l'on souhaite être multiplateforme.

Ce qui rassure avec Qt, c'est sa maturité tout en restant moderne et innovant. Même si la maturité est rarement compatible avec l'innovation comme c'est le cas avec Qt Quick.

Citation:

---

Je pense qu'il y a un gros avantage à cela (même si je ne l'ai pas encore testé) : il doit très certainement être assez simple d'utiliser des librairies JS pour compléter les fonctionnalités de QML (édition de fichier ODF, PDF, ...)

---

Malheureusement non, les librairies JS sont pour la plupart très orientés web et donc très dépendantes de l'environnement d'un navigateur web.

Citation:

---

Envoyé par loupium

Malheureusement non, les librairies JS sont pour la plupart très orientés web et donc très dépendantes de l'environnement d'un navigateur web.

---

C'est dommage, car pour moi Qt à malgré tout un gros point noir : impossible de générer, éditer, ... des fichiers ODF.
En tout cas j'ai pas trouvé, et j'avais un espoir avec JS. Il va falloir que je continue à me contenter des outils proposés via Python :cry:

Je suis de loin l'évolution de Qt depuis quelques années, sans jamais avoir eu l'occasion de m'en servir autrement que pour quelques petits projets perso.

Je me demande si l'adoption de Qt n'est pas aussi facilité par le fait que Qt n'est pas qu'un framework pour la partie GUI. Il existe aussi des modules pour gérer du XML (j'ai découvert Qt en cherchant des parseurs XML) et pour gérer des BDD (que j'ai utilisé dans ma première application Qt). Pensez-vous que ces modules non GUI soient un gros plus pour l'adoption de Qt ou pensez-vous au contraire qu'ils sont complètement marginaux et insignifiant en regard de la partie GUI ?

De même, que pensez-vous de l'impact des différents bindings de Qt ? Comme Jiyuu, je suis un amateur de Python (au même titre que Qt en fait) et le binding PyQt a été une de mes motivations à apprendre Python car je connaissais déjà Qt. On pourrait imaginer le cheminement inverse.

Citation:

---

Envoyé par Bktero

Je suis de loin l'évolution de Qt depuis quelques années, sans jamais avoir eu l'occasion de m'en servir autrement que pour quelques petits projets perso.

Je me demande si l'adoption de Qt n'est pas aussi facilité par le fait que Qt n'est pas qu'un framework pour la partie GUI. Il existe aussi des modules pour gérer du XML (j'ai découvert Qt en cherchant des parseurs XML) et pour gérer des BDD (que j'ai utilisé dans ma première application Qt). Pensez-vous que ces modules non GUI soient un gros plus pour l'adoption de Qt ou pensez-vous au contraire qu'ils sont complètement marginaux et insignifiant en regard de la partie GUI ?

---

En ce qui me concerne c'est LA raison pour laquelle j'utilise Qt avec Python. La puissance de Qt avec la facilité de Python c'est juste du bonheur. Mais il pourrait y avoir encore plus puissant et plus simple... Ouufff Qt Quick arrive. Il lui manque encore quelques outils (pilotes des principaux SGDB, écrirture et/ou lecture XML, ODF, PDF, ...).
Et pour être proche de la perfection, il faudrait que son utilisation "standalone" soit optimisée.
Je rassure les amateurs de C++ et Python, pour moi il faut aussi que Qt Quick reste compatible avec ces langages pour des gros projets.

Citation:

---

Envoyé par Bktero

De même, que pensez-vous de l'impact des différents bindings de Qt ? Comme Jiyuu, je suis un amateur de Python (au même titre que Qt en fait) et le binding PyQt a été une de mes motivations à apprendre Python car je connaissais déjà Qt. On pourrait imaginer le cheminement inverse.

---

Un peu comme ça : http://pyotherside.readthedocs.org/en/latest/ ... en cours d'étude pour en percevoir la réelle utilité en particulier si on peut facilement rendre une appli 100% QML "standalone".

Citation:

---

Envoyé par Bktero

Je suis de loin l'évolution de Qt depuis quelques années, sans jamais avoir eu l'occasion de m'en servir autrement que pour quelques petits projets perso.

Je me demande si l'adoption de Qt n'est pas aussi facilité par le fait que Qt n'est pas qu'un framework pour la partie GUI. Il existe aussi des modules pour gérer du XML (j'ai découvert Qt en cherchant des parseurs XML) et pour gérer des BDD (que j'ai utilisé dans ma première application Qt). Pensez-vous que ces modules non GUI soient un gros plus pour l'adoption de Qt ou pensez-vous au contraire qu'ils sont complètement marginaux et insignifiant en regard de la partie GUI ?

---

Pour ma part, que ce soit sur des projets personnels ou professionnels, l'utilisation des modules non GUI de Qt a toujours été un gain de temps dans le développement d'applications (utilisation d'une BDD, utilisation du réseau, exécution de processus externes, gestion de XML). Ce sont des modules éprouvés, ceux-ci utilisent également le principe des signaux/slots pour les traitements asynchrones.

Après je suis d'accord avec jiyuu, Qt doit rester compatible avec C++ et Python. Mais il me semble que QtQuick/Qml sont des modules Qt (DLL présentes dans le répertoire bin) et nécessite un lancement en C++ ou Python pour pouvoir démarrer.

J'avais commencé à travailler sur GTK, j'ai été assez vite limité et suis passé sur Qt.

Du coup, j'ai du me mettre au C++ ( je ne suis pas programmeur de métier ).

GTK ( GTK=Gimp ToolKit ), ça sert qu'à l'interface graphique, Qt il y a plein de sous-modules.

Je reviendrais pas en arrière.

Les portages PyQt et Qml permettent de faire un développement très vite et sans de grosses connaissances.

En framework, honétement je vois pas mieux.

Citation:

---

Envoyé par charlespf

Après je suis d'accord avec jiyuu, Qt doit rester compatible avec C++ et Python. Mais il me semble que QtQuick/Qml sont des modules Qt (DLL présentes dans le répertoire bin) et nécessite un lancement en C++ ou Python pour pouvoir démarrer.

---

Pour repréciser un peu mes précédentes remarques, pour moi l'idéal serait :

• de pouvoir créer des applications complexes en utilisant QML associé à C++ ou Python :fleche: euuhh ... ... ... oui ce que l'on peut faire actuellement en fait :P ;
• créer des applications simples sans être obligé d'utiliser C++ ou Python pour les exécuter, ce qui reviendrai à distribuer uniquement le code QML et qmlscene. Reste à savoir comment qmlscene peut-être "distribué" sans embarqué trop de choses à coté.

Exemple : un client mail pourraient être créer graphiquement en QML, mais tout le code pour le faire fonctionner exigera sûrement du code Python ou C++. À contrario, pour une calculatrice simpliste le code peut être fait à 100% en QML. Je trouve alors dommage "d'alourdir" l'application avec une couche C++ ou Python uniquement pour le lancer.

Qu'en pensez-vous ?

Je suis d'accord avec vous. Après chacun aura ses affinités avec les environnements.
J'ai surtout l'impression qu'on nous impose à utiliser QtQuick/QML pour faire du développement d'applications graphiques. Le jour où l'on m'imposera cela, je commencerais à regarder une autre framework.

Citation:

---

J'ai surtout l'impression qu'on nous impose à utiliser QtQuick/QML

---

Ce n'est qu'une impression probablement due à l'exposition de Qt Quick. Normal, les news portent plus souvent sur les nouveautés que sur la maturité.

Je confirme : ce n'est qu'une impression.
Maintenant je trouve qu'une GUI est bien plus rapide à écrire en QML qu'en pur Qt. Pour cette raison je pense que de plus en plus de GUI seront faites en QML.

Mais rien n'empêche le programmeur d'utiliser du pur Qt :)... S'il a envie de se compliquer la vie après tout :P

Il y a t-il des différences de performances entre QML et C++ pour la création de la GUI ? Je présume qu'il faut démarrer une sorte de moteur avec QML alors qu'avec C++, c'est directement exécutable. Si je pense que cela est mineur pour de nombreuses appli, cela doit faire une différence pour d'autres (jeux un peu évolués, applications de sons,...).

:salut:

Personnellement je ne pense pas. Mais n'ayant pas fait de tests il m'est difficile d'avoir une position ferme. Il faut savoir par contre que QML est un langage interprété ... Cela peut-il jouer sur la GUI ???

En tout cas si ceci est avéré je pense que ça ne durera pas. Qu'est ce qui me fait dire ça ?
Deux choses, la première c'est que beaucoup de news concernant les nouvelles versions de Qt traitent du travail fait sur la partie Qt Quick et les termes "performances", "amélioraton moteur de rendu", etc sont souvent utilisés. Je pense donc que beaucoup d'efforts sont faits pour rendre QML très performant.

La deuxième concerne le monde pour lequel Qt Quick a été développé : le monde du mobile. Je ne suis pas assez calé en développement C++ et encore moins en développement mobile, mais pour moi si Qt Quick a été mis au point c'est pas pour avoir un truc qui marche moins bien.

Je ne sais pas si le développement d'appli mobile (pour rappel il est question des GUI ici) en pur Qt est faisable, mais une chose est sûre si Qt Quick existe c'est bien parce qu'il y avait une ou plusieurs difficultés de faire les GUI en C++.

Non ?

++

J

Citation:

---

Envoyé par imikado

Tant que des projets comme Gnome et Xfce continuent sous GTK, il n'y aura pas de vague d'adoption pour Qt ;)...

---

Je vais me permettre quelques questions naïves suite à cette réponse.

J'ai toujours utilisé des applications GTK aussi bien que Qt. Et cela aussi bien sous KDE que sous LXDE et XFCE. Et donc :
- Quel est le problème à utiliser des applications GTK sous KDE ?
- Quel est le problème à utiliser des applications Qt sous GNOME ?
- Et enfin, quel est l'avantage de Qt sur GTK sous Windows ? sachant que les applications OpenSource que j'utilise sous Windows sont GIMP, OpenOffice et Mozilla ... et qu'aucune ne me pose de problème particulier sous Windows.

Ce qui me semble probable, c'est qu'il y a des applications qui a mon avis ne passeront pas sous Qt. Par exemple GIMP. ;)

:salut:

Très sincèrement je pense qu'il n'y a aucun problème, c'est juste une question de rationalisation et de "surcharge" de ton PC. Par exemple si tu utilises KDE, il semble plus logique d'utiliser des applications basées sur Qt quand cela est possible plutôt que de réinstaller d'autres :

• tu peux espérer avoir déjà certaines dépendances d'installé pour d'autre programmes ;
• compatiblité des programmes entre eux ;
• ...

Je pense aussi qu'il y avait un autre point important : l'esthétique. En effet, et en ce qui concerne les applis GTK sous KDE, je me souviens que celles-ci n'étaient pas très belle alors que sous GNOME elles l'étaient.
Aujourd'hui ceci n'est majoritairement plus vrai, enfin sous KDE car il me semble qu'il existe paquet "gtkAsKde".

Pour l'utilisation d'appli Qt ou GTK sous windob alors là ... ... aucune idée. Je pense que d'un point de vue programmeur il s'agit surtout d'habitude. Je ne connais franchement pas GTK alors que je commence tout juste à maitriser Qt : donc je code en Qt.
D'un point de vue utilisateur, le lambda va surtout choisir le programme en fonction de ce qu'il cherche... qu'il soit fait en GTK ou en Qt ne lui importe peu je pense. Pour l'utilisateur-programmeur amateur comme moi, si j'ai le choix je prendrai du Qt, juste par chauvisme :P ...

Pour GIMP à coup sûr tu ne le trouveras jamais en Qt, mais un QIMP peut-être ;)

Citation:

---

Envoyé par Cenwen

le passage à Qt 5 (surtout la suppression de la crainte que les dev avaient quand Qt 3 est passé à Qt 4) :

---

Moi, je suis pour la biodiversité et je trouve utile d'avoir le choix dans plusieurs toolkits.
Cela diminue le nombre de sueurs froides dont il est question plus haut.

Certains semble ignorer que GTK propose tout une série d'interfaces, dont une en C++ et une autre pour Python.
Le C n'est indispensable que si vous voulez créer vos propres widgets.

Je trouve qu'en ce moment GTK a pour faiblesses principales.
* les incompatibilités qui rendent le passage de GTK-2 à GTK-3 assez douloureux
* une documentation difficile à utiliser pour le débutant,
* être moins complet que Qt.

Pour le pb de MAC OS X, il faut rendre hommage à Andreas Fink http://pdb.finkproject.org qui compile pour cet OS un grand nombre de logiciels, GTK ou pas.

L'indépendance n'existe que par la connaissance et la diversité.

Citation:

---

Envoyé par Pierre GIRARD

Je vais me permettre quelques questions naïves suite à cette réponse.

J'ai toujours utilisé des applications GTK aussi bien que Qt. Et cela aussi bien sous KDE que sous LXDE et XFCE. Et donc :
- Quel est le problème à utiliser des applications GTK sous KDE ?
- Quel est le problème à utiliser des applications Qt sous GNOME ?
- Et enfin, quel est l'avantage de Qt sur GTK sous Windows ? sachant que les applications OpenSource que j'utilise sous Windows sont GIMP, OpenOffice et Mozilla ... et qu'aucune ne me pose de problème particulier sous Windows.

Ce qui me semble probable, c'est qu'il y a des applications qui a mon avis ne passeront pas sous Qt. Par exemple GIMP. ;)

---

Jyiuu a déjà bien répondu à ma place
Ce que j'avais en tête c'est surtout la mémoire: pour utiliser une application on charge en mémoire les librairies graphiques

Si on lance un environnement de bureau utilisant gtk ou Qt, il vaut mieux continuer (autant que faire se peut) utiliser des applications utilisant les mêmes

Après, effectivement Gimp utilise Gtk (dont il est à l'origine), mais certains lui préfère Krita quand ils evoluent en KDE

Citation:

---

Envoyé par imikado

...Après, effectivement Gimp utilise Gtk (dont il est à l'origine)...

---

Je sais, :D c'est bien pour ça que je doute de voir un jour Gimp passer à Qt. Je ne connais pas Krita, mais je vais l'essayer ;)

Cela étant, pour un non programmeur, et à par quand une application se nomme K... ou G... (et encore, Gwenview est me semble-t-il Qt et pas GTK), comment savoir si c'est une application Qt ou GTK ou autre...? Par exemple, Mozilla, Open/LibreOffice, Sane/XSane, Scribus, Apache, Lazarus, VLC, Wine, FileZilla, Opera ... et bien d'autres.

Et pour ce qui est des performances, même en chargeant à mort Linux avec des applications GTK sur un environnement Qt, je n'ai jamais réussit aussi bien à plomber les performances qu'avec Windows et des applications purement Windows. :aie:

Cela étant, merci pour ces réponses. ;)

Oui c'est une habitude prise depuis que j'ai commencé à utiliser GNU/Linux (mandrake à l'époque) après avec la RAM qu'on a aujourd'hui, à part en machine virtuelle, on peut oublier cette recommandation.
Si ce n'est pour économiser l'espace disque des librairires et autres dépendances :)

:salut:

Lorsque je parlais de surcharge PC je parlais bien d'espace disque. Concernant les performances, c'est sûr qu'un Windob en 2 mises à jour il est déjà totalement à la ramasse. C'est d'ailleurs marant ça : chez la fenêtre mise à jour = pertes de performances (:weird::weird::weird:) chez le pinguin = gain de performance (en général :mrgreen:) )... moi je dis : y en a qui n'ont pas bien compris l'utilité des MAJ :aie:

En ce qui concerne la question : comment savoir si une appli est du Qt ou du GTK je vois 4 possibilités :

• tu passes un coup de fil au développeur et tu lui demandes ;
• le développeur le précise sur son site ou tout autre communiqué ;
• tu regardes dans le "À propos de" s'il y a l'indication ;
• tu regardes les sources.

Bon la quatrième tu oublies sous windob... :mrgreen:

Citation:

---

Envoyé par Jiyuu

En ce qui concerne la question : comment savoir si une appli est du Qt ou du GTK je vois 4 possibilités :

• tu passes un coup de fil au développeur et tu lui demandes ;
• le développeur le précise sur son site ou tout autre communiqué ;
• tu regardes dans le "À propos de" s'il y a l'indication ;
• tu regardes les sources.

Bon la quatrième tu oublies sous windob... :mrgreen:

---

Sinon un coup de ldd ou de dependancy walker ça marche aussi.

Citation:

---

Envoyé par arnolddumas

Sinon un coup de ldd ou de dependancy walker ça marche aussi.

---

Bien vu le ldd... l'avais oublié lui.