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)

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

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

++

[Jiyuu]

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.

++

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

[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

[charlespf]

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

++

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

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

[Freem]

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.

[loupium]

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.

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.