Version imprimable
tous les Control SWT ont une méthode isReparentable() qui informe de la possibilité de modifier le parent donné à la construction, on peut donc modifier le parent de certains widgets via la méthode setParent(Composite), mais je ne saurais pas dire lesquels je n'ai jamais eu besoin de cette fonctionnalité (donc je ne trouve pas cela trés contraignant, ça exige un peu plus d'organisation puisque on ne peut pas créer un Control sans lui attribuer de parent).
je réponds pour préciser que je n'en n'utilise pour l'instant aucun, je suis justement là pour me renseigner:?
Swing, car je connais pas l'autre :-S
J'utilise les 2.
J'utilise Java depuis seulement 2 ans et demi, venant du C.
J'ai commencé par utiliser SWT, d'approche plus simple. Je n'ai franchement eu aucun probleme. Puis j'ai utilise dans un deuxieme temps JFace, specifiquement pour les possibilites d'edition dans les listes.
Autant SWT est clair et facile a utiliser, autant JFace est assez "bazardeux" et surtout mal isolé. Mais on n'y arrive.
Je me suis mis a Swing, dans un deuxieme temps, une fois que j'ai ete a l'aise en Java. Swing est plus difficile d'utilisation que SWT, mais beaucoup plus dans l'esprit Java. Le seul reel point faible de Swing sont ses Layout natif. Un fois que l'on a re-ecrit un GridLayout dans l'esprit de celui de SWT (il y en a plusieurs en licence libre d'ailleurs), tout va bien. Swing est largement superieur a SWT pour l'adaptabilite des widgets au besoin specifiques des applications.
Au niveau des performences, a part le JFileChooser de Swing largement plus lent que celui de SWT, il n'y a pas de probleme particulier. Swing est plus lent, oui, mais sauf cas tres specifique, l'utilisateur final ne s'en appercoit pas. En tout cas mes utilisateurs ne se sont pas appercu du passage de SWT a Swing.
Actuellement, j'ai divers cas de figure: appli utilisant que SWT, appli utilisant que Swing et enfin appli utilisant les 2. Ce qui m'a ammener a avoir des dialogues ecrit dans les 2 systemes et partageant le meme controleur, sans soucis particulier.
J'ai une preference pour Swing qui me permet une meilleur adaptabilite au besoin de mes utilisateurs, et qui est plus dans l'esprit Java. Mais franchement SWT et Swing sont 2 solutions viables, la premiere plus facile d'acces surtout si on vient de win32, et l'autre plus customisable et plus "Java".
Dernier mot cote portabilite: ces appli tournent sous Windows et GTK. Nous avons eu des problemes de portabilite avec Swt aussi bien qu'avec Swing, mais evidement pas les memes :) Une fois qu'on les connait, rien d'insurmontable.
Utilisateur SWT
Pour la simple raison que je ne trouve pas Swing très beau et parfois un peu trop vieux.
Bon après je n'ai jamais essayé, je ne connais que SWT...^^
Mais bon, je crois qu'il existe des L&F pour Swing, ça pourrait m'intéresser un jour ou l'autre.
Je trouve SWT léger, facile à manipuler (Eclipse + Visual Editor) et sympa avec le coté natif (il supporte très bien mon thème vista sur un xp)
Il suffit juste de ne pas laisser le look and feel par défaut.
Après on ne peut plus dire que c'est moche.
Moi j'ai mis SWING, mais vu que j'ai jamais utilisé swt je peux pas dire lequel des 2 est le plus facile à appréhender. En revanche, mon impression sur swing, c'est qu'après un petit temps d'adaptation (c'est la partie de mon initiation à Java qui a été la plus dur) il est plutôt intuitif, et donne rapidement des résultats sympa :mouarf:
Perso j'utilise les 2.
J'utilise SWT dans un cadre particulier (raisons professionnelles) mais je préfère malgré tout Swing
Bonjour,
Moi je suis débutant en java, et pour le moment je préfère apprendre les 2. Mais j'ai une petite remarque, j'ai installé eclipse et Netbeans 6.5 et franchement, sur certains points eclipse est beaucoup meilleur que NetBeans. Premièrement NetBeans est parfois vraiment trop long à l'exécution, surtout si tu change de fenêtre et l'interface de NetBeans est vraiment moche par rapport à celle d'eclipse qui tourne plus vite et il est plus beau . Par contre ce qui me plait avec NetBeans c'est qu'il y a un éditeur visuel c'est pour cela que je l'utilise, quant à eclipse je vois qu'il y en beaucoup qui parle de Visual Editor + Eclipse mais je ne sais pas où je peux trouver ça ?!! :(:(
En bref, si NetBeans est créé avec Swing ça veut dire qu'il faut s'attendre à une lenteur significatif des applications et une fenêtre tout en violet (D'ailleurs je ne sais pas comment la modifier :(). Par contre eclipse qui est créé avec swt on voit bien le résultat, applications plus belles à voir et qui s'exécutent plus vite.
Encore un qui tourne avec une version de java antidéluvienne et qui ne connait pas la notion de look & feel.Citation:
Envoyé par othmane126
Grosso modo à l'heure actuelle niveau performances SWT et Swing c'est quasi identique. La différence entre les deux frameworks se fait plutôt au niveau des orientations prises et des arichtectures utilisées.
Par définition, ce n'est pas possible.. SWT sera toujours plus performant que Swing même si la puissance des machines permet aujourd'hui de "masquer" ce défaut.Citation:
Envoyé par sinok
Il n'y a pas de "par définition".Citation:
Par définition, ce n'est pas possible.. SWT sera toujours plus performant que Swing même si la puissance des machines permet aujourd'hui de "masquer" ce défaut.
SWT utilise les composants du système ou les dessine (comme Swing) s'ils n'existent pas.
De plus les implémentations étant différentes, il a déjà été montré que dans certains cas, (tableau avec beaucoup de données), SWT était plus lent.
"Par définition" signifie que SWT utilise des objets natif, contrairement à Swing.
Et je t'ai répondu que ce n'était pas du 100% natif, puisque les composants qui n'existent pas sur le système sont dessinés.
Voir aussi le problème des "gros" tableaux.
Avec SWT il y a également la problématique de la libération des ressources...
Avec Swing, la question ne se pose pas vraiment...
Ceci dit, n'ayant pas essayer SWT, je ne peux pas dire lequel est mieux (si c'est le cas d'ailleurs), il me semble juste que c'est un peu naze d'utiliser un langage portable avec des bibliothèques spécifiques à l'OS... pour moi, syntaxe error !
Pour Swing (ça au moins je connais un peu ;)), on peut faire beaucoup de chose, de la à dire simplement, peut-être pas...
Je suis d'accord avec ce qui a déjà été dit, la séparation données/ihm est forte et sympa...
Les listener restent un rien "sac de noeuds" pour moi, et les cascades d'événements qui sont interrompues parce que le listener du dessus c'est gaufré est franchement gonflant... (surtout pour trouver l'erreur)
Pour la rapidité... bof... mais ça suffit...
Comme beaucoup je vote Swing!
J'y suis habitué et j'aurais beaucoup de mal à faire des application graphique en JAVA sans le Swing...
Seul problème qui a déjà été évoqué, la gestion avec les Layouts qui peut devenir très difficile dès qu'on essai de créer des interfaces un tant soit peu évoluées.
J'utilise uniquement Swing depuis mes débuts en java.
Choix évident pour éviter les soucis natifs et la gestion mémoire.
Mais par contre j'ai toujours trouvé cela un peu lent, particulièrement le JFileChooser, mais aussi les actions en général.
J'ai pu comparer recensement et c'est irréfutable: Swing à ce coté un peu lent et tous ceux qui disent ne pas voir la différence sont aveugle ou ont une machine surpuissante.
C'est pour ça que je m'intéresse à SWT qui a pour inconvénient principal de nécessiter plusieurs distributions, une par OS, mais est ce bien si gênant ?
--- Edit ---
J'ai découvert quelque chose de remarquable qui permet d'utiliser SWT sans en connaitre les rouages, c'est une espèce de convertisseur Swing=>SWT instantané: SwingWT
Il suffit d'ajouter les class de SwingWT en bibliothèque ainsi que SWT et de changer les importations "javax.swing" en "swingwtx.swing"
Merveilleux, la puissance de SWT et la simplicité de Swing.
Swing pour ma part mais jamais testé SWT!
Swing , car je viens de windev :mrgreen:
un exemple avec awt :
http://faqjava.developpez.com/?page=...oublebuffering
pour melanger awt et swing je ne croix pas que c une bonne idee raison :
http://faqjava.developpez.com/?page=graphique_general
:calim2: