Discussion :

[LittleWhite]

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 ?

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

[Jiyuu]

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

[Invité]

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...

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

[Atem18]

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

T'as aussi Ubuntu.

[KsassPeuk]

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.

[azias]

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:

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)

[Jiyuu]

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.

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

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

[imikado]

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

[Jiyuu]

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...

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 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 : faut complètement être taré pour coder en Java , alors qu'une appli Qt Quick est si simple à faire.

[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, mais je peux me tromper.

++

[imikado]

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"

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

Dirk also found the Qt Creator IDE to be incredibly good

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

[Pierre GIRARD]

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.

[Jiyuu]

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 ...

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

[imikado]

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

[vingt sens]

@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.

[Markand]

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.

[Cenwen]

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.

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.

[pvincent]

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é.

[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

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

[Jiyuu]

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, ...)