Les bindings de Qt sont-ils réellement matures ?

Version imprimable

22/08/2010, 20h55
dourouc05

Bonjour,

Qt est un framework multiplateforme, notamment utilisé pour la création de GUI mais pas seulement, développé principalement pour le C++. Jusqu'à la version 4.5, une version en Java était développée en même temps. C'était alors le premier binding officiel.

D'autres bindings sont apparus depuis la création du framework : l'un des plus connus, PyQt, développé par River Bank Computing pour le langage Python, qui n'est pas disponible en LGPL, seulement en GPL 2/3 ou en licence commerciale. Il est fort proche de la version C++, parfois trop, rendant certaines parties très peu "pythoniques". Pour pallier le manque de support de la LGPL, Nokia a mis à disposition PySide, un autre binding Python de Qt, dont l'API est strictement identique, facilitant la migration de l'un vers l'autre.

Signalons que d'autres bibliothèques fortement utilisées par les utilisateurs de Qt, à savoir Qwt pour les graphiques et Qt Mobility pour le développement sur mobiles sont aussi disponibles : PyQwt pour PyQt et PySide Mobility pour PySide.

Il existe encore toute une série d'autres bindings de Qt, aux états d'avancement fort différents : QtAda pour Ada, Qyoto et qt4dotnet pour le framework DotNet (principalement C#), QtD pour le D, QtHaskell pour le Haskell, QtRuby pour Ruby, etc.

Certains sont parfois des montages un peu fallacieux :

Citation:

Envoyé par _skip

Le binding .Net est QtJambi compilé avec IKVM, ce qui fait quand même beaucoup de bidules expérimentaux empilés.

Et vous, de votre côté, qu'en pensez-vous ? Utilisez-vous des bindings Qt pour un autre langage ?
S'y intègre-t-il relativement bien ? Vous permet-il d'écrire du code d'une manière semblable à une API prévue pour ce langage ? N'y a-t-il pas d'incompatibilité de paradigme ? Qt est prévu pour des langages orientés objet, ne pose-t-il pas de problème particulier aux langages fonctionnels, logiques... ?
Est-il suffisamment stable pour une utilisation quotidienne ? Sa structure lui permet-elle d'atteindre cette stabilité sans surcouche de surcouche ?

Voir aussi

:fleche: La rubrique Qt de Developpez.com
:fleche: La rubrique Python de Developpez.com
:fleche: Une introduction à PyQt, par Olivier Girardot

:fleche: PySide
:fleche: PyQt
:fleche: PythonQt
:fleche: Feu QtJambi
23/08/2010, 10h39
_skip

Les bindings de Qt sont-ils réellement matures ?

Cet article m'a fait réalisé que les bindings semblent en fait assez aboutis, je pensais à tort qu'ils n'étaient pas tant plus que des proof of concept :aie:
23/08/2010, 11h25
o.girardot

très honnetement je les trouve très agréable à utiliser, et surtout rapide et peu verbose. Un peu dans l'esprit pythonique.

Une chose regretable c'est peut-être le fait que ce soit des bindings et pas des projets indépendants comme QtJambi, mais bon l'intéraction en c++ est tellement simple que ça se comprend aussi.
23/08/2010, 19h05
_skip

Il y a juste un petit bémol dans la licence commerciale, le fait qu'on te demande de livrer ton application avec un runtime python signé.

Mais python s'en sort bien avec son binding Qt, c'est peut être le langage qui tire le mieux son épingle du jeu. Côté java, QtJambi a été stoppé et franchement j'ai pas une grosse confiance en son avenir communautaire. Puis le binding .Net est QtJambi compilé avec IKVM, ce qui fait quand même beaucoup de bidules expérimentaux empilés.

Et d'autres relèvent carrément de la plaisanterie.
23/08/2010, 19h18
o.girardot

Pour le coté commerciale de la chose, je trouve très bonne l'initiative de Nokia autour de PySide qui en plus d'être en LGPL conserve une API compatible avec PyQt (qui est plus ancienne).

Mais c'est sûr que pour l'avenir (et mes prochains articles) je vais plus me focaliser sur PySide vu son coté moins restrictif.
23/08/2010, 21h46
yan

Citation:

Envoyé par _skip

Puis le binding .Net est QtJambi compilé avec IKVM, ce qui fait quand même beaucoup de bidules expérimentaux empilés.

Pas QYoto. C'est du code C# interfaçant les lib C++. Et ça marche plutôt pas mal. Pour avoir essayé 2-3 fois sous linux c'est même très agréable!!!

Sous windows c'est encore très compliqué pour compilé les dll .net. Mais j'ai pas encore re-testé . Sous linux c'est déjà tous fait sur la plupart des distribue.
24/08/2010, 15h27
_skip

Citation:

Envoyé par yan

Pas QYoto. C'est du code C# interfaçant les lib C++. Et ça marche plutôt pas mal. Pour avoir essayé 2-3 fois sous linux c'est même très agréable!!!

Sous windows c'est encore très compliqué pour compilé les dll .net. Mais j'ai pas encore re-testé . Sous linux c'est déjà tous fait sur la plupart des distribue.

Oui je l'ai vu...

Je sais pas trop, l'idée est intéressante mais la présentation du projet est toute pourrie, en plus tous les liens sur la page wiki sont des 404. Bref ça me met pas trop en confiance. Surtout que le multi-plateforme ne semble pas être leur préoccupation.
24/08/2010, 17h30
yan

Citation:

Envoyé par _skip

Je sais pas trop, l'idée est intéressante mais la présentation du projet est toute pourrie, en plus tous les liens sur la page wiki sont des 404. Bref ça me met pas trop en confiance. Surtout que le multi-plateforme ne semble pas être leur préoccupation.

Il fait son bout de chemin sous linux mais inconnue sous windows. Quelques personnes travaillent sur les modif pour marcher avec windows.

Vue que C# avec mono se développe de + en + sous linux, je pense que qyoto suit le mouvement et devient petit à petit une alternative intéressante à gtk#.

Côté portabilité, il y a surtout des problèmes de cmake et de compilateur C++. A part cela il ne devrait pas y avoir trop de problème. Tu devrais même pouvoir compiler l'exe sous linux et l'utiliser sous windows si tu as les dll correspondante sur les deux plateformes.
24/08/2010, 20h15
_skip

La librairie de référence de mono, à savoir gtk# est pas mal puissante déjà et elle-aussi multiplateforme moyennant un déploiement du runtime gtk sous windows. Ce que Qt pourrait apporter sur la table, c'est surtout son éditeur nettement plus puissant que celui de monodevelop je suppose.

Il faut que je regarde de plus près pour voir jusqu'où ils ont été avec Qyoto, s'ils proposent la conversion des slots en delegate et ce genre de chose...
24/08/2010, 20h27
yan

Citation:

Envoyé par _skip

Il faut que je regarde de plus près pour voir jusqu'où ils ont été avec Qyoto, s'ils proposent la conversion des slots en delegate et ce genre de chose...

tu peux regarder ici.
27/08/2010, 08h52
Julien Bodin

Utiliser Qt avec Java c'est toujours d'actualité ou c'est mort ?
Il n'y a plus de support après la version 4.5.
27/08/2010, 09h32
o.girardot

QtJambi (implémentation Java de Qt) n'est plus supporté officiellement par Nokia, néanmoins la communauté est active et le projet continue.

Après justifier l'utilisation devant un supérieur hiérarchique peut devenir un peu compliqué avec l'arrêt de l'implication de Nokia depuis Mars 2010...
Mais la communauté est vivante et le projet loin d'être mort.
27/08/2010, 10h54
_skip

Citation:

Envoyé par o.girardot

QtJambi (implémentation Java de Qt) n'est plus supporté officiellement par Nokia, néanmoins la communauté est active et le projet continue.

Après justifier l'utilisation devant un supérieur hiérarchique peut devenir un peu compliqué avec l'arrêt de l'implication de Nokia depuis Mars 2010...
Mais la communauté est vivante et le projet loin d'être mort.

Personnellement je ne suis pas super optimiste en ce sens car maintenir la version java bien synchronisée avec l'évolution de Qt va demander pas mal de ressources. Il est possible que l'on voit apparaître des soucis dans le support de l'éditeur visuel notamment.

Honnêtement, professionnellement parlant je préférerai payer une version commerciale maintenue par une véritable entreprise plutôt que faire confiance à la communauté. Ou alors carrément revenir à swing et investir dans un outil comme http://www.formdev.com/.

Je suis pas anti open-source, mais pour que ça bouge, c'est bien s'il y a un soutien financier solide derrière ainsi qu'une entreprise ayant une vision produit. La preuve, regardez mono, depuis que Novell est derrière ils ont une trentaine de dévs qui sont dessus, ça avance affreusement vite. Rien à voir avec l'époque ou c'était une POC faite par quelques hobbyistes.