Discussion :

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

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

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

PySide
PyQt
PythonQt
Feu QtJambi

[_skip]

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

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

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

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

[yan]

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.

[_skip]

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.

[yan]

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.

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

[yan]

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.

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

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

[_skip]

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.