Discussion :

[khalous91]

Bonjour,

C'est quoi la différence entre les interfaces SWING AWT et SWT??

J'ai un test la semaine prochaine a passer dans une entreprise sur swing. pouvez vous me donner un bon tuto avec de la pratique ci possible qui me donnera de bonnes bases solides sur SWING merci.

Amicalement

[dinobogan]

AWT est la bibliothèque graphique qui existe depuis le début de Java. A l'époque, c'était le seul moyen de faire du graphique. Ce n'est pas pur Java, ses fondations sont évidemment dépendantes du système hôte (il faut bien à un moment sortir de toute abstraction pour faire du concret sur la machine...). Nombreux sont ceux qui s'accordent à dire qu'il ne faut plus l'utilisée.
Swing est le remplaçant de AWT. C'est du pur Java et pose ses fondations sur AWT (normal aussi, inutile de réinventer la roue pour accéder au système hôte).
Quant à SWT, c'est une bibliothèque "concurrente" à Swing. C'est un projet libre issu d'Eclipse et n'a rien à voir avec les concepteurs de Java. C'est un projet à part. Il est fondé sur son propre code pour chaque système hôte puis possède par dessus du code Java. C'est exactement le même principe que Swing : du code natif selon le système hôte puis une grosse couche Java pour tout unifié quelque soit le système.

[khalous91]

AWT est la bibliothèque graphique qui existe depuis le début de Java. A l'époque, c'était le seul moyen de faire du graphique. Ce n'est pas pur Java, ses fondations sont évidemment dépendantes du système hôte (il faut bien à un moment sortir de toute abstraction pour faire du concret sur la machine...). Nombreux sont ceux qui s'accordent à dire qu'il ne faut plus l'utilisée.
Swing est le remplaçant de AWT. C'est du pur Java et pose ses fondations sur AWT (normal aussi, inutile de réinventer la roue pour accéder au système hôte).
Quant à SWT, c'est une bibliothèque "concurrente" à Swing. C'est un projet libre issu d'Eclipse et n'a rien à voir avec les concepteurs de Java. C'est un projet à part. Il est fondé sur son propre code pour chaque système hôte puis possède par dessus du code Java. C'est exactement le même principe que Swing : du code natif selon le système hôte puis une grosse couche Java pour tout unifié quelque soit le système.

Merci c'est très clair! en gros c'est la même chose, juste la librairie qui changent ( logique )
juste une question c'est quoi le système hôte?

merci

[nchal]

juste une question c'est quoi le système hôte?

Bah, c'est le système sur lequel tu lance l'application. En l’occurrence ton système d'exploitation si tu le lances toi (Windows ou OSX ou une distro linux).

[joel.drigo]

Salut,

Tout dépend dans quels niveaux de détails ce test risque de descendre. Il y a de nombreuses différences de pratique entre Swing et SWT (déjà un problème : ce n'est pas le même niveau d'API). Il y a aussi de nombreux défauts de conception à mon sens (ou, disons, de bonne pratique de programmation), mais il en existe aussi dans Swing : les deux sont parfois dû à l'époque à laquelle les fonctionnalités ont été implémentée (je pense en particulier à certaines constantes servant d'options qui mériterait d'être sous forme de enum, dans les 2 environnements).

En AWT/Swing, l'architecture est plus "carrée" :

1. d'une part, on peut distinguer les "Container" (Conteneur) et les "Component" (Contenu) : les seconds vont dans les premiers
2. d'autre part, de nombreux concept sont sous forme d'interface : on peut plus facilement généraliser le code. Par exemple toute forme (Rectangle, Line, Ellipse...) est un Shape. Pour remplir un espace, on utilise un Paint, dont Color est une version particulière.
3. il n'existe qu'un seul thread "graphique", l'Event Dispatch Thread. Il est créé automatiquement.
4. Globalement, on est censé exécuter toute méthode d'une classe Swing dans l'EDT, mais Swing est permissif (on peut appeler des méthodes sur le thread qu'on veut, ce qui est souvent pratique, tant qu'il n'y a pas d'effet de bord dû à cette pratique).
5. Tout composant peut être créé indépendamment et être mis dans un conteneur, puis retiré, puis remis dans un autre, etc...
6. Les composants standards d'UI sont doublés d'une couche dite d'UI justement qui gère le look and feel (l'apparence) et le comportement
7. On peut étendre les composants Swing pour en faire des versions personnalisées
8. Les écouteurs d'évènements sont spécialisés (il y a une interface dédiée), et les composants émetteurs ont les méthodes "addMachinListener()" qui vont avec...
9. Les constantes utilisées pour les options sont attachées au composant avec lequel elles sont utilisables en plus d'être dans une classe de constantes (SwingConstants)
10. La notion de renderer permet une grande souplesse pour faire des composants à l'affichage très personnalisé

En SWT/JFace (JFace est l'API qui se fonde sur SWT pour proposer un système plus MVC-like (je trouve le MVC de Swing plus rigoureusement MVC que celui de JFace, amha. Il est en tout cas beaucoup plus souple en Swing).

1. on distingue également les Conteneurs et les Contenus, mais il faut également distinguer les "Ressource" des "Widget". Les classes qui étendent Resource sont des composants de base (par exemple les couleurs, les images, les polices...) : toute instance créée doit absolument être libérée (appel à dispose()) à partir du moment où on s'en sert plus, un peu comme le close() des InputStream/OuputStream de Java). Si on ne le fait pas, un handle système étant créé pour ces instances, cet handle peut persister y compris après que l'application soit arrêtée (par exemple par kill -9), et on peut se retrouve sans plus aucun handle, ce qui oblige à rebooter la machine. Les Widgets sont des composants de plus haut niveau, qui sont soit fondés sur des composants du système directement, soit sur d'autres widgets. On doit également les libérer, mais pas forcément tous (par exemple, il suffit de libérer une fenêtre pour que tous les widgets qui s'y trouvent soient libérés, en cascade).
2. Il y a peu de concepts généraux : par exemple la classe Color et la classe Pattern (Texture) sont deux classes différentes (alors qu'en Swing, on peut manipuler les deux concepts par une interface commune Paint). L'avantage aussi dans ce cas, c'est qu'on peut implémenter sa propre texture dynamique, alors qu'on ne peut pas en SWT. Il n'y a pas d'interface en commun en Rectangle, Path et Region par exemple, trois classes qui pourtant permettent de traiter le clipping en SWT (alors qu'en Swing, on peut tout traiter par Shape).
3. A la base d'une interface SWT, on a une instance de classe Display : cette classe intègre la gestion du thread graphique. Ce qui veut dire que si on créé plusieurs Display, on peut avoir plusieurs interfaces graphiques indépendantes au niveau du thread.
4. On doit obligatoirement appeler toutes méthodes de Resource ou de Widget dans le thread graphique SWT sinon on obtient une exception (comme si en Swing, pour affecter le texte d'un JLabel, il fallait faire un invokeLater.
5. Tout widget, sauf la fenêtre (Shell en SWT) doit être créé avec un parent existant : on ne peut donc pas créer des composants librement et les assembler et désassembler comme on veut. Pour retirer un widget de son conteneur, il faut la disposer(), donc la récréer à zéro si on veut la mettre dans un autre composant
6. L'apparence peut être géré par un système de thèmes, et même de feuilles de styles CSS
7. On ne peut pas étendre les composants SWT : il faut absolument procéder pâr encapsulation dans un Composite (équivalent du JPanel), ce qui complique certaines implémentation
8. S'il existe dans les composants JFace des écouteurs spécialisés, tous les évenements SWT sont gérés à partir d'une classe unique de Listener, et d'un type d'événement (qui est une constante, voir le point suivant à ce sujet)
9. Les constantes sont toutes uniquement dans une classe de constantes (SWT) : seule la JavaDoc permet de connaitre les constantes utilisables dans le contexte d'un composant en particulier. Comme les types d'évenements sont aussi gérés par constantes, il faut toujours regarder dans la javadoc pour savoir quel évènement on peut écouter sur un composant. Là où la completion peut aider en Swing, ce n'est pas le cas en SWT.
10. Les possibilités de personnalisation du rendu sont très limités, et souvent compliqués à mettre en oeuvre, même pour un TableViewer par exemple (équivalent de la JTable). Il n'y a pas de composants équivalent à JLayer par exemple, ni de système pour décorer l'équivalent des JScrollPane, mais les composants sont beaucoup plus intégrés dans l'environnement graphique de la machine (par exemple, le champ recherche du mac avec ses icônes spécifiques, peut être affiché facilement en SWT, alors qu'en Swing, il faut le simuler entièrement). Le revers de la médaille est qu'il peut y avoir des différences de visuel entre les OS, ou de comportements (par exemple, les boutons avec image de taille quelconque fonctionne tout seul sur Windows, mais s'affiche tronqué puisque de taille fixe sur MacOsX.

Il y a beaucoup d'autres choses à dire, comme au sujet des différences dans le traitement de l'agencement (Layout Manager), par exemple, ou des Images, aussi. Il y a aussi l'aspect Draw2D, et les composants indépendant du "système" (ceux dont le nom commence par C, comme CLabel (par opposition à Label), ou CCombo (par opposition à Combo)), etc.
On peut noter que l'API reste globalement Java 1.4 (donc pas, ou peu en tout cas, de types paramétrés.


Pour le tutoriel sur Swing et SWT, va dans la rubrique Tutoriels Java de Developpez, et consulte pour commencer le tutoriel de JM DOUDOUX, le plus complet pour moi.

[khalous91]

Salut

Merci Joel ainsi que les autres pour vos réponses

bien cordialement