Je me lance, ca fait une bonne quinzaine d'année qu'on s'est pas fait un petit flamewar sur Gtk vs Qt vs C++, ça me rappellera mes brulures de jeunesse !
L'ex-développeur de GtkMM Guillaume Laurent m'avait expliqué à une époque que Gtk souffrait d'un vrai handicap pour la génération de binding: le C qui est utilisé pour décrire l'ensemble des widgets et autres éléments de Gtk n'est pas un langage suffisamment expressif pour en générer automatiquement une version C++. Il faut un travail manuel considérable d'annotation et d'aide au générateur pour arriver à une solution qui se tienne. La conséquence est que ce travail a eu tendance à épuiser les mainteneurs motivés et que GtkMM a souvent été fortement à la traîne de Gtk, le rendant au mieux difficilement utilisable en dehors des widgets très standards et au pire, inutilisable.
A jeter un coup d'oeil sur le site, cela n'a plus l'air d'être le cas aujourd'hui mais ton commentaire laisserai entendre que si en fait.
Un autre handicap de gtkmm, c'est clairement que les dév qui aiment bien Gtk ne sont absolument pas attiré par le C++. Il faut une combinaison assez particulière de développeur aimant bien Gtk et le C++ pour travailler ou utiliser Gtk. C'est peut-être un peu moins vrai aujourd'hui où le C++ a gagné des lettres de noblesses même dans le monde du logiciel libre.
A l'inverse, Qt bénéficie de pas mal d'avantages pour la génération de binding: le C++ et les classes de retour gérant la mémoire intelligemment (du type QString) fournissent une information suffisamment riche pour automatiser une grosse partie du travail. C'est ce qu'a fait Phil Thompson pour les binding Python-Qt et Richard Dale pour tous les autres (KDE principalement). PyQt bénéficie d'un autre très gros avantages: Phil Thompson a basé une partie de son business de consulting dessus, ce qu'il fait qu'il maintient ça depuis 15 ans avec une régularité et une rigueur qui m'impressionnent. Toutes les versions de Qt sont supportées dans la semaine qui suit et les bindings manquants concernent des parties de Qt vraiment peu utilisées.
L'outil qu'il utilise pour générer ses bindings - sip - a même été repris par WxPython pour refondre les binding vers WxWidget en Python 3 (projet Phoenix).
Du coup, si tu aimes le C++, mieux vaut rester côté Qt. Et j'en dira autant pour le Python sans prendre un gros risque.
# Gtk et le C++
Posté par Philippe F (site web personnel) . En réponse au journal Mes activités open sources / libres "récentes". Évalué à 8.
Je me lance, ca fait une bonne quinzaine d'année qu'on s'est pas fait un petit flamewar sur Gtk vs Qt vs C++, ça me rappellera mes brulures de jeunesse !
L'ex-développeur de GtkMM Guillaume Laurent m'avait expliqué à une époque que Gtk souffrait d'un vrai handicap pour la génération de binding: le C qui est utilisé pour décrire l'ensemble des widgets et autres éléments de Gtk n'est pas un langage suffisamment expressif pour en générer automatiquement une version C++. Il faut un travail manuel considérable d'annotation et d'aide au générateur pour arriver à une solution qui se tienne. La conséquence est que ce travail a eu tendance à épuiser les mainteneurs motivés et que GtkMM a souvent été fortement à la traîne de Gtk, le rendant au mieux difficilement utilisable en dehors des widgets très standards et au pire, inutilisable.
A jeter un coup d'oeil sur le site, cela n'a plus l'air d'être le cas aujourd'hui mais ton commentaire laisserai entendre que si en fait.
Un autre handicap de gtkmm, c'est clairement que les dév qui aiment bien Gtk ne sont absolument pas attiré par le C++. Il faut une combinaison assez particulière de développeur aimant bien Gtk et le C++ pour travailler ou utiliser Gtk. C'est peut-être un peu moins vrai aujourd'hui où le C++ a gagné des lettres de noblesses même dans le monde du logiciel libre.
A l'inverse, Qt bénéficie de pas mal d'avantages pour la génération de binding: le C++ et les classes de retour gérant la mémoire intelligemment (du type QString) fournissent une information suffisamment riche pour automatiser une grosse partie du travail. C'est ce qu'a fait Phil Thompson pour les binding Python-Qt et Richard Dale pour tous les autres (KDE principalement). PyQt bénéficie d'un autre très gros avantages: Phil Thompson a basé une partie de son business de consulting dessus, ce qu'il fait qu'il maintient ça depuis 15 ans avec une régularité et une rigueur qui m'impressionnent. Toutes les versions de Qt sont supportées dans la semaine qui suit et les bindings manquants concernent des parties de Qt vraiment peu utilisées.
L'outil qu'il utilise pour générer ses bindings - sip - a même été repris par WxPython pour refondre les binding vers WxWidget en Python 3 (projet Phoenix).
Du coup, si tu aimes le C++, mieux vaut rester côté Qt. Et j'en dira autant pour le Python sans prendre un gros risque.