Discussion :

[puybaret]

Non en fait c'est un plugin qui passe toute l'interface en Swing: EoS

Hum, donc comparer les performances de Swing et SWT/JFace dans ces conditions, c'est un peu biaisé non ?

Eclipse sous Napkin ça a de la gueule

Moi aussi, je trouve ce look and feel très sympa. Pour faire des maquettes d'écran "propres", ça a l'air impec !

[sinok]

Hum, donc comparer les performances de Swing et SWT/JFace dans ces conditions, c'est un peu biaisé non ?

Ils ont utilisé SWTSwing qui permet d'appeler du Swing en codant en SWT. Donc il y a évidemment une surcouche et une perte de perf. De même quelques tucs ne tournent pas encore comme la gestiond de la molette pour les ScrollBars.
Enfin ils ont dû s'muser pour mettre ça en place

[puybaret]

Ils ont utilisé SWTSwing qui permet d'appeler du Swing en codant en SWT. Donc il y a évidemment une surcouche et une perte de perf.

Ouaips, on est donc d'accord, cette comparaison, c'est du n'importe quoi dans ces conditions !
Si octal (dont je ne doute pas des compétences) pouvait nous confirmer que c'est bien ainsi qu'il a testé Eclipse sous Swing, ce serait bien...

[octal]

Non en fait c'est un plugin qui passe toute l'interface en Swing

Non désolé, la version première d'Eclipse été réellement écrite sous SWING, mais VRAIMENT sous SWING. Dans le temps SWT n'été pas encore née, il été en cours de développement. De plus Eclipse n'été pas encore ce que l'on connait actuellement, c'été encore à l'état de prototype pour en faire un environnement de développement pour les langages Objets chouchou d'IBM, et donc principalement destiné à Smaltalk. Les perf n'étant pas au rendez vous, ils décider de promouvoir SWT (en rachetant la société qui l'avait développé) et de l'utiliser comme base pour Eclipse (tel qu'on le connait actuellement).
J'ai plusieurs écrit fait par des gens d'IBM qui été impliqué dans le projet et qui décrivent l'historique complet de swt et des différentes version d'Eclipse depuis la naissance du projet, je ne peux malheureusement pas les diffuser pour des raisons de copyright

[puybaret]

Au passage, si octal cherchait un peu, il en trouverait des problèmes de portabilité de SWT. Sous Mac OS X, le pont SWT / AWT n'est toujours pas complètement implémenté, ce qui empêche un paquet de plugins de fonctionner correctement sous Eclipse (comme Visual Editor par exemple).
Sous ce système, il suffit par exemple d'inclure la lib SWT sans l'utiliser dans un projet Swing, pour l'empêcher de fonctionner correctement !

[octal]

Au passage, si octal cherchait un peu, il en trouverait des problèmes de portabilité de SWT. Sous Mac OS X, le pont SWT / AWT n'est toujours pas complètement implémenté, ce qui empêche un paquet de plugins de fonctionner correctement sous Eclipse (comme Visual Editor par exemple).
Sous ce système, il suffit par exemple d'inclure la lib SWT sans l'utiliser dans un projet Swing, pour l'empêcher de fonctionner correctement !

je ne doute pas qu'il puisse y avoir de pb de compatibilité ici et là, d'ailleur allez y voir meme les sources des framework soit disant portable meme écrit en C++ qui sont plein de IFDEF et de DEFINE ...
Cependant pour des appli FULL SWT et CLEAN et non basée sur des Pont et des bricollages et bidouille pour récupérer des bout d'interfaces ça et là, je n'ai jamais eu de pb sous MacOSX/GTK/Winxx ...
je demanderai plutot à voir une appli "correctement" écrite qui aurait des pb sous MacOSX à cause de Swt!!! et pour la portabilité je vous proposerai aussi d'aller voir les forum réserver à SWING surtout en ce qui concerne les éléments fortement liés à l'OS comme les boites de dialogue d'ouverture de fichier ou les messages box ... qui soient refusent de s'ouvrir soient ne s'affiche que partiellement !!!

[puybaret]

Non désolé, la version première d'Eclipse été réellement écrite sous SWING, mais VRAIMENT sous SWING.

Ravi de pouvoir discuter avec toi octal, est-ce qu'on peut encore la trouver quelque part cette version ? Si tu l'as encore, l'as-tu testé avec Java 5 ou 6 ?

Les perf n'étant pas au rendez vous, ils décider de promouvoir SWT (en rachetant la société qui l'avait développé) et de l'utiliser comme base pour Eclipse (tel qu'on le connait actuellement).

Ah d'accord ! On parle d'une version de Swing / JRE qui date de plus de 7 ans.
Mais tout le monde sait que maintenant Swing est bien plus performant ! Des preuves : NetBeans, JBuilder, IDEA sont écrits avec Swing. Ce serait à refaire, je suis prêt à parier que les développeurs d'IBM auraient préférer jouer sur le long terme, en espérant une amélioration des performances. Ils vont devoir traîner SWT jusqu'à la nuit des temps maintenant !

[puybaret]

[...]pour des appli FULL SWT et CLEAN et non basée sur des Pont et des bricollages et bidouille pour récupérer des bout d'interfaces ça et là, je n'ai jamais eu de pb sous MacOSX/GTK/Winxx ...

Et Visual Editor, c'est peut-être pas un plugin Eclipse standard ? Pourquoi je ne pourrais pas m'en servir correctement sous mon Mac ?

je demanderai plutot à voir une appli "correctement" écrite qui aurait des pb sous MacOSX à cause de Swt!!! et pour la portabilité je vous proposerai aussi d'aller voir les forum réserver à SWING surtout en ce qui concerne les éléments fortement liés à l'OS comme les boites de dialogue d'ouverture de fichier ou les messages box ... qui soient refusent de s'ouvrir soient ne s'affiche que partiellement !!!

Pour les boîtes d'ouverture de fichier, il suffit d'utiliser la classe FileDialog d'AWT et le tour est joué.
Quand on prend la peine d'utiliser Swing correctement, il n'y aucun problème d'intégration au système. Crois-moi, j'ai écrit tout un bouquin où j'ai programmé la même appli en AWT/Swing et en SWT/JFace ! D'ailleurs en cherchant la petite bête, SWT fonctionne moins bien sous Mac puisqu'Apple propose des classes Java pour gêrer le menu application qui ne fonctionnent pas sous SWT.

[octal]

Je suis désolé de voir ce débat stérile tourner vers une bagare eternelle SWING vs Others .... j'aurai préférer lire des post d'autres membre avec leurs expérience...
bref ...
J'utilise moi meme SWING pour certain projet et j'en suis très satisfait. Croyez moi, Je ne pousse personne à passer à SWT et oublier SWING. Je veux juste dire qu'il faut éviter de dénigrer SWT parce qu'on le connait pas (pas utilsé professionnellement).
Je n'ai jamais dénigré les qualités de SWING, relisez mon premier post, j'ai clairement dis que SWING s'améliore de plus en plus et que la vitesse est très correcte meme sur des machine modestes, et avec la JRE5.xxx les performance ont été boustées (et je m'en réjouit, parce que j'espère que l'on va bientot profité de ces évolution dans le monde de l'embarqué ... donc en version compact). Cela dit, on ne pourra jamais, avec une SURcouche destinée à caché l'OS avoir les performance d'une librairie JNE utilisant directement les lib de l'OS. Java6 va peut être changer la donne vu que le moteur graphique va utiliser une librairie PORTEE déjà sur plusieurs OS et qui est OpenGL (et il parait meme que sun prévoit l'utilisation de l'accélération graphique matérielle... to be continued ... ). Ce que je veux dire c'est que ce n'est pas parce que les lib faisant partie de la JNE et interagissant avec l'OS (pour le support gui) sont fournies par SUN sur plusieurs plateformes qu'elle sont forcément meilleures que celle fournies par IBM pour le support de SWT sur le multiplateforme. SUN ne fait pas non plus de magie, pour voir SWING afficher un pixel elle fourni bien une lib native pour appeler le GDI ou GTK ou tout autre low level lib. IBM Fait pareil pour SWT. Ce n'est pas parce que ces lib sont installées avec la JRE que c'est meilleur que les lib bas niveau de SWT. Avec un peu de bonne volonté on pourrai avoir un outil d'install qui installerai le tous directement ... peut être qu'avec le passage à l'Open Source SUN apprendra à donner du leste ... En plus SWING a pris vraiment beaucoup de temps pour murir, alors que SWT n'en ai pratiquement qu'à la première version (qui ait été utilisée professionnelement).

Pour les gens d'IBM il est vrai qu'ils devront trainer les SWT, comme sun se doit de trainer la totalité de la JRE et ses lib JNE pour les différents OS, mais personnelement je pense que la révolution future qui risque de changer tous ca et d'uniformiser tout cela c'est la virtualisation (surtout avec le support de la virtualisation au niveau hardware). à suivre ...

Bonne journée

[puybaret]

Je suis désolé de voir ce débat stérile tourner vers une bagare eternelle SWING vs Others .... j'aurai préférer lire des post d'autres membre avec leurs expérience...

Hum... en relançant le débat sur les performances de Swing vs SWT et l'intégration dans le système de ces deux bibliothèques, il ne faut pas s'étonner de la tournure que prend le débat !
Mais comme je l'ai déjà résumé ailleurs, la bibliothèque SWT/JFace est plus simple à mettre en œuvre, mais offre moins de possibilités que Swing pour personnaliser les composants d'une interface utilisateur. Qu'en pensez-vous ?

[octal]

je ne suis pas étonné de la tournure que ca prend ...

Question:
que voulez vous dire par "...pour personnaliser les composants d'une interface utilisateur..."?

[KKI]

J'utilise SWING, portabilité oblige.

Par contre, je vous conseille de regarder du coté de layouts plus riches et plus souples que les traditionnels (TableLayout, ou SpringLayout) et utilisés NetBeans

[[Nean]]

Je tiens à préciser ma réponse à ce sondage en disant que j'utilise Swing principalement parceque c'est le seul que j'ai essayé et que je ne connais pas SWT. De plus SWING me convient plutôt bien, donc pourquoi changer ?

[X-plode]

Tout à fait d'accords avec GLDavid

[Kharneth]

Salut !

Je débute en Java et j'utilise donc les 2 pour me familiariser avec les 2 bibliothèques. Pour le moment, je trouve SWT un peu plus simple d'utilisation car elle est assez similaire à la prog Win32 que je connais bien.

Ce qui m'a frappé avec SWING, c'est l'absence de contrôle graphique et de la gestion de l'évènement Paint. D'après ce que j'ai compris, il faut hériter un nouveau composant et surcharger l'évènement Paint, ce qui est plutôt lourd et peu pratique. Ou alors peut être utiliser AWT (j'ai pas encore testé mais ce n'est plus SWING dans ce cas).

Merci pour ce sondage, ça répond à quelques unes de mes questions.

[unknoweb]

slt !!!!!!

pour ma part j'utilise swing pourquoi ??? j'ai débuter avec et awt je connait pas mais déja tester vite fais ........ je viens de débuter la programmation donc voila sinon dommage que la fusion de quelques composant entre swing et awt ne ce fais pas ....... sinon JGoodies je sais pas comment l'utiliser si quelqu'un pouvais morienter ........

[soft0613]

Bonjour, j'ai voté SWT car je l'utilise bien plus que SWING.

J'ai auparavant débuté sur SWING mais j'ai été vite attiré par SWT car je trouve qu'il est plus simple a comprendre, au niveau des constructeurs qui sont pratiquement tous du même type (le conteneur et un int pour le style du composant) et parce que la gestion du positionnement est trés facile, je trouve que les quelques gestionnaire de placement fournis permettent vraiement de remplir facilement toutes les fonctionnalités demandées.

Ce qui est dommage c'est le manque de documentation qui existe vis-à-vis de l'utilisation avancée de SWT/JFace comparé à SWING... mais bon avec de la volonté et un peu de patience on finit toujours par trouver.

[eclesia]

J'ai auparavant débuté sur SWING mais j'ai été vite attiré par SWT car je trouve qu'il est plus simple a comprendre

Je m'amuse en ce moment a "transcrire" des interfaces SWT vers Swing...
... je m'amuse a la folie ... en particulier avec les equivalant des JList... ListViewer je crois.

je ne sais pas comment vous les faites les interfaces SWT, ou si ca vient de celui qui a fait celle ci en particulier. Mais c'est vraiment bizzare. Et je trouve ca de loin plus tordu que Swing.

[soft0613]

Moi je trouve que l'ajout automatique au parent lors de la construction est plus pratique que l'utilisation de la méthode add() par exemple, d'autant plus qu'il n'y a pas non-plus de problème avec la nécessité d'appelle à getContentPane() dans certains cas ou à l'ajout au gestionnaire de positionnement plutôt qu'au composant parent (je pense au Box) en SWT si tu sais créer et postionner un compsant tu sais le faire avec tous les autres et les gestionnaires de positionnement sont d'une simplicité déconcertante pas besoin de se prendre la tête avec la vaingtaine de champs à configurer du GridBagLayout ou avec la nécessité d'utiliser un setPreferredSize() il suffit de savoir utiliser le GridLayout qui est d'une simplicité à toute épreuve et tu peux créer toutes les interfaces graphiques que tu veux.
Ce sont diverses raisons dans ce genre qui m'ont fait trouver SWT plus simple à apprendre et à prendre en main, ceci-dit SWING a une grande richesse de composants qu'SWT n'as pas encore et c'est bien dommage.

[eclesia]

l'ajout automatique au parent lors de la construction

ha merci de l'info, ce n'est donc pas le gars qui code mal .

Pour moi ca me semble plus naturel de creer un bouton comme n'importe quel object, avec different constructeur, voir des constructeurs static. Et ensuite venir ajouter mon composant sur le JPanel. Je vois ca comme une feuille de papier qu'on "punaise" sur un panneau d'annonce, le add est logique quand on le voit comme ca.

Ce n'est pas contraignant d'avoir a spécifier le parent des la construction? ou est ce qu'on peut en changer par la suite?