Java Swing ou Java Qt ?

Question

Quelqu'un ayant une grande expérience de Qt et de Java Swing peut-il me dire s'il utiliserait Swing ou Qt sous Java, et pourquoi ?

Deuxièmement, quel est l'impact commercial de l'utilisation de Qt ? Est-il raisonnablement populaire ou aurai-je du mal à trouver des développeurs Qt expérimentés ? Y a-t-il d'autres impacts commerciaux dont je devrais être conscient ?

UPDATE : Je suis plus intéressé par les impacts techniques et commerciaux de Swing vs Qt que par le type de licence/frais puisque dans mon cas le coût n'est pas une préoccupation.

Answer 1

D'après mon expérience (un an de Qt, plusieurs années de Swing).

Swing :

• Pro :
  • Disponible sur toute installation Java. Pas besoin d'envoyer de code supplémentaire
  • Vous pouvez écrire vos propres widgets personnalisés en Java.
• Contra :
  • Swing est vieux . Il n'y a pas eu de mise à jour du noyau depuis des années et il n'y en aura jamais. Si vous envisagez d'utiliser Swing, prenez un bon wrapper qui rendra l'utilisation de Swing beaucoup plus simple.
  • Swing est difficile à comprendre et à utiliser, surtout si vous êtes habitué à la programmation d'interfaces utilisateur sous Windows. (Un seul mot : Layouts).
  • Il n'y a pas beaucoup de widgets puissants dans le jeu de base. Il vous manquera surtout une bonne grille de données.
  • Pour un bon look&feel, vous avez besoin d'une bibliothèque supplémentaire.

Qt :

• Pro :
  • Un ensemble complet de widgets puissants
  • Facile à utiliser et à apprendre
  • Bonne documentation
  • Bon soutien
  • Développement actif
  • Utilise des widgets natifs et les intègre dans une API commune à toutes les plateformes.
• Contra :
  • Vous devez envoyer des fichiers supplémentaires
  • Qt est écrit en C++, vous y accédez donc via une bibliothèque d'habillage. Si vous devez implémenter un composant personnalisé complexe, les choses peuvent devenir difficiles.

Si vous pouvez engager un développeur Swing expérimenté, essayez-le. Si vous ne le pouvez pas et si vous devez repartir de zéro, je vous suggère de vous opposer à Swing. Avec Qt, vous obtiendrez des résultats en quelques heures et en ne vous arrachant que peu de cheveux. Swing est puissant, mais il ne cherche pas à le cacher. Vous vous retrouverez donc à vous débattre avec l'API et les valeurs par défaut qui avaient un sens en 1996 mais plus aujourd'hui.

Qt a une courbe d'apprentissage beaucoup plus raide et l'API est beaucoup plus cohérente, sans compter que Qt a été amélioré au cours des sept dernières années alors que Swing ne l'a pas été (voir ci-dessous). KDE est basé sur Qt, il y a donc beaucoup de gens qui l'utilisent et la plupart d'entre eux n'ont que peu de temps (disons quelques heures ici et là) et la plupart peuvent gérer Qt après peu de temps. Ce que vous ne pouvez tout simplement pas dire pour Swing.

Il existe beaucoup de documentation sur Swing, mais la plupart d'entre elles ne couvrent que les cas les plus courants que vous pouvez découvrir vous-même dans la Javadoc. Si vous avez besoin de quelque chose de plus complexe et si vous recherchez une vue d'ensemble, quelque chose qui vous donne une idée de la façon de combiner les choses pour obtenir le résultat souhaité, je n'ai rien vu de gratuit et je ne peux pas non plus recommander de livre sur Swing car j'ai arrêté de les regarder il y a cinq ans.

Si vous regardez Java 7, vous verrez que Sun envisage de travailler sur l'API Swing. Mais : Java 7 sera disponible dans deux ans, il n'y a pas d'engagement pour ces éléments de travail et, enfin, le plus important : Pouvez-vous passer à Java 7 lorsqu'il sera disponible ?

Mise à jour : Il semble qu'il y ait il n'y aura pas de mises à jour de Swing pour Java 7 après tout. Ce qui est dommage. Nous nous retrouverons avec un cadre d'interface utilisateur intégré datant de la fin des années 90 qui n'est plus à la pointe du progrès. Etant un vieil amoureux de l'Amiga, je sais ce que ça fait d'être abandonné. Merci, Swing, c'était un bon moment.

Answer 2

Je ne suis pas du tout d'accord avec la réponse d'Aaron Digulla. en ce qui concerne le Swing .

J'ai trouvé que Swing n'était pas la meilleure conception et qu'elle était un peu alambiquée, mais qu'elle était raisonnablement simple et utilisable, et qu'en fin de compte tout à fait bien pensé. De plus, il est certain es capable de ce qui est requis pour presque toutes les applications GUI.

En utilisant le LAF natif, l'application ressemblera et fonctionnera suffisamment comme une application native pour recevoir une note de passage (IMO).

Pour ce qui est de la partie sur les mises en page... c'est... vrai que les mises en page Swing sont un peu difficiles à utiliser et nécessitent des imbrications (parfois assez nombreuses) pour obtenir les résultats souhaités, mais le concept des mises en page est l'un des meilleurs aspects des interfaces graphiques en Java. Prenez le temps de comprendre ce qu'ils font pour vous. et procurez-vous une bonne mise en page basée sur des tableaux (par ex. MatrixLayout TableLayout, JGoodies FormLayout ou MigLayout) qui éliminera 99 % des imbrications. Une mise en page basée sur des tableaux simplifiera également votre interface graphique et fera en sorte que le code reflète mieux le résultat visuel final.

Donc, mon conseil est que si QT fait les choses d'une manière que vous préférez ou fournit des fonctionnalités que Swing n'offre pas, alors, par tous les moyens, examinez-le. fourni par que vous êtes satisfait de la distribution de ses composants Java et natifs avec votre application, et qu'il cible les plates-formes sur lesquelles vous voulez fonctionner (ou pourriez vouloir fonctionner à l'avenir).

Sinon, il est difficile de battre la flexibilité de Swing, le fait qu'il soit intégré dans chaque installation Java et sa capacité à personnaliser facilement l'apparence et le comportement.

Oh, et pour être juste, je n'ai pas regardé QT avant - Mais j'ai environ 6 10 ans de développement actif de Swing et AWT, comprenant 1 application AWT déployée commercialement et 3 applications Swing (non triviales), plus un certain nombre d'applications Swing personnelles. Ce qui est peut-être plus important, c'est que j'ai mis en œuvre une boîte à outils d'interface graphique légère entièrement fonctionnelle au-dessus d'AWT, très analogue à Swing mais avec une architecture de composants et d'événements complètement différente, qui a été déployée avec succès dans le commerce.

Answer 3

Sachez que Qt Jambi ne sera plus disponible sous peu. http://www.qtsoftware.com/about/news/preview-of-final-qt-jambi-release-available . Mon interprétation est qu'après la sortie de la version 4.5 en mars, Jambi sera dans le même bateau que les liaisons Qt pour d'autres langues - à la communauté de les maintenir.

En ce qui concerne vos questions, j'ai quelques années d'expérience avec Swing et je travaille avec Qt Jambi depuis un mois, et je suis assez mitigé.

D'une part, je suis particulièrement déçu par le paradigme modèle/vue de Qt. En revanche, créer un arbre éditable dans Swing, en utilisant un modèle complètement différent de Swing, est un jeu d'enfant. Quelques heures de travail. Après une semaine de lutte, j'en suis venu à la conclusion qu'il n'est tout simplement pas possible de faire une telle chose dans Jambi 4.4. (Je ne sais pas pour 4.5) La seule solution que j'ai trouvée dans Qt est de lier les données aux classes de modèle Qt en sous-classant QStandardItemModel et QStandardItem. (Alors que QAbstractItemModel est très capable dans Qt C++, il est littéralement inutilisable dans Qt Jambi).

D'autre part, Qt Jambi me donne accès aux incroyables outils de dessin QGraphicsView, et je ne connais pas de bibliothèque Java qui puisse être comparée. Pour moi, c'est la puissance de Qt Jambi - il vous donne accès en Java à d'excellents outils de dessin 2D et GL qui ne sont pas vraiment disponibles en Java autrement.

Mon conseil est que si vous devez construire une application qui n'utilise que des widgets d'interface utilisateur standard comme des tableaux, des arbres, des menus, etc. La mise en page dans Swing n'est pas si difficile, vraiment, surtout avec des outils comme NetBeans. Cependant, si vous avez besoin de GL ou d'une toile sur laquelle peindre, Qt Jambi peut être intéressant.

Answer 4

Commentaire de Pete est juste. Pour ceux qui ont besoin d'une boîte à outils plus puissante basée sur le swing, consultez Jide. http://www.jidesoft.com/ .

Answer 5

En ce qui concerne Qt vs Java PDF que Deepak a présenté, il a clairement été écrit il y a de nombreuses années. Depuis lors, la machine virtuelle de Java s'est énormément améliorée, de sorte que les problèmes de mémoire et de performance ne sont plus un problème. L'article discute même de la validité de l'utilisation du garbage collector, ce que je trouve hilarant !

Ensuite, en ce qui concerne les modèles de programmation, le modèle signal-slot a été présenté comme supérieur à MVC, la seule mesure étant le nombre de lignes de code nécessaires pour obtenir le même effet ! Ce qui a été oublié dans ce document est que le code de Java est clairement auto-documenté, contrairement à celui de Qt.

Je ne dis pas que Qt est pire que Swing. Je dis simplement que ce document ne devrait PAS être utilisé comme un argument. Les deux premières réponses donnent la meilleure description des deux frameworks en discutant uniquement de leurs forces et faiblesses, sans comparer les modèles de programmation et en tirant des conlusions de l'air.