FAQ Plateforme EclipseConsultez toutes les FAQ
Nombre d'auteurs : 6, nombre de questions : 26, dernière mise à jour : 13 janvier 2019 Ajouter une question
Cette FAQ a été réalisée à partir des questions fréquemment posées sur les forums de www.developpez.net/forums et de l'expérience personnelle des auteurs.
Nous tenons à souligner que cette FAQ ne garantit en aucun cas que les informations qu'elle propose sont correctes. Les auteurs font leur maximum, mais l'erreur est humaine. Cette FAQ ne prétend pas non plus être complète. Si vous trouvez une erreur, ou que vous souhaitez nous aider en devenant rédacteur, lisez ceci .
Sur ce, nous vous souhaitons une bonne lecture.
L'équipe Java/Eclipse
- Définition de SWT et de JFace
- Quelles sont les différences entre SWT et Swing ?
- Quels sont les avantages et inconvenients de SWT par rapport à Swing ?
- Quels sont les Widgets SWT ?
- Où trouver des exemples sur SWT ?
- [3.0-] Comment lancer une application SWT ?
- Comment lancer une application SWT ?
- Comment inclure du Swing dans une application SWT et inversement ?
- Pourquoi mon widget qui hérite d'un widget SWT plante à l'exécution ?
- Comment packager une application SWT pour Java Web Start ?
- [2.x] Comment afficher un calendrier ou un sélecteur de date en SWT ?
- Comment afficher un calendrier ou un sélecteur de date en SWT ?
- Comment empêcher une fenêtre (Shell) d'être disposée à sa fermeture ?
SWT est une bibliothèque qui sert à construire des interfaces graphiques en Java, au même titre que les bibliothèques AWT et Swing.
La particularité de SWT est de déléguer l'affichage graphique au système d'exploitation. Concrètement, à travers SWT vous utilisez les MFC, Gtk ou autres.
JFace est une surcouche de SWT, davantage orientée objet, qui amène de plus un modèle MVC et des fonctionnalités supplémentaires.
Swing est une API "lightweight", c'est-à-dire qu'elle redessine tous les composants graphiques (widgets) à l'aide des primitives de Java2D.
SWT quant à lui, utilise les API graphiques du système d'exploitation, c'est-à-dire que ses widgets sont dessinés directement par ce dernier.
En d'autres termes, pour afficher un bouton, Swing va dessiner un rectangle et placer un label au millieu, alors que SWT va simplement demander au système d'exploitation de se charger de cette opération.
Sous SWT, chaque objet Java représentant un élément graphique, n'est qu'un wrapper vers du code natif.
Ici l'idée est de simplement présenter quelques pistes de reflexion, afin de vous aider à faire votre choix.
Prenez tout de même le temps d'approfondir le sujet, en vérifiant par exemple si ce qui est dit ici reste valable dans le temps.
Avantages
- Non standard : vous pouvez distribuer vous même SWT avec votre application ce qui permet de gérer finement le versioning, de bénéficier rapidement des BugFixs et des mises à jour
- Natif : SWT s'adapte automatiquement au Look and Feel du système d'exploitation. Une application Java sous SWT va s'adapter automatiquement à un windows customisé à l'extrême, ou à un Gtk avec un thème exotique
- Petite API : SWT est une petite API, avec un nombre limité de widgets, et peu d'héritage, ce qui en fait une API facile à prendre en main
- Consomation mémoire : la consomation mémoire de SWT est plus faible que celle de Swing
- Vous pouvez bénéficier du projet Eclipse RCP comme framework de développement
- Open Source
- Linkable : si vous prévoyez de compiler votre application avec GCJ et Gnu-Classpath, il est possible d'utiliser SWT facilement (il existe une version de Eclipse native)
- Bonne intégration : possibilité d'utiliser COM, des plug-ins, le browser web natif pour rendre du HTML
Inconvénients
- Non standard : vous devez distribuer vous même SWT avec votre application, ce qui va alourdir votre distribution et parfois compliquer le déploiement
- Non standard : moins de compétences sur SWT, moins de doc, moins d'aide sur le forum de DVP
- Natif : on subit les limitations de la plate-forme sous-jacente (taille maximum d'un champ texte, nombre d'image, pas de centrage des champs header, des tables, ...)
- Gestion mémoire : il est nécessaire de faire un .dispose() sur tous les éléments graphiques pour liberer la mémoire du composant natif qu'il représente
- Petite API : SWT/Jface est une petite API, et il manque des choses comparé à Swing
- Portabilité : Comparée à Swing et à la version Windows, la version Gtk de SWT reste lente ( plus d'info)
- Pas d'applet possible
- Pas de SandBox possible dans Java Web Start, à cause des accès natifs
Vous pouvez voir les widgets SWT sur cette page : Widgets SWT .
Chaque widget est présenté avec un exemple et sa Javadoc.
L'équipe de développpement de SWT tient à jour une page d'exemples SWT Snippets .
Vous pourrez y trouver de nombreux exemples d'utilisation de chacun des widgets SWT, ainsi que la réponse à des questions plus complexes, comme comment lancer une tâche longue dans un Thread , gérer le Drag and Drop , ...
Pour lancer une application SWT, vous devez bien sûr avoir les jar SWT dans le classpath, mais aussi déclarer les librairies natives. Celles-ci se trouvent dans le sous-répertoire de plug-ins org.eclipse.swt.[OS]
- Sous Eclipse 3.1M5+ : menu Run > Application SWT
- Sous Eclipse : menu Run > Run Java Applicaton > New > Arguments > VM Arguments et ajouter -Djava.library.path=c:\eclipse\plugins\org.eclipse.swt.win32_2.1.0\os\win32\x86
- Enfin, pour le distribuer vous devez ajouter dans la ligne de commande -Djava.library.path=chemin_vers_librairies
Bien sûr, vous devrez adapter ces lignes de commandes à votre OS et à la version de SWT utilisée.
Dans les versions récentes d'Eclipse, pour lancer une application SWT, il suffit juste d'ajouter le jar de SWT correspondant à votre architecture (org.eclipse.swt.gtk.linux.x86_3.4.0.xxx.jar par exemple pour Linux/x86)
Ce jar peut être récupéré du dossier plug-ins de votre installation Eclipse.
Pour inclure du Swing dans du SWT, voici un exemple Snippet154.java .
Pour inclure du SWT dans du Swing, c'est cet exemple qu'il faut observer Snippet337.java .
Vous avez quelques autres exemples dans la partie Swing/AWT de cette page SWT Snippets .
Il est fortement déconseillé d'hériter d'un widget SWT.
En effet, même si SWT est une API Java, les objets que l'on utilise ne sont que des représentations du code natif d'un toolkit graphique. De fait, l'héritage n'est pas forcément supporté (Gtk est codé en C par exemple).
En conséquence, chaque widget (sauf bien sûr 'Composite') utilise un mécanisme pour bloquer l'héritage : là une méthode protected void checkSubclass() throws SWTException. Cf. la Javadoc .
Peut-être vous posez-vous la question de savoir pourquoi le mot clé final n'a pas été utilisé dans ce genre de cas ?
Tout simplement parce que le systême de check au runtime n'empêche pas l'héritage. Ce qui fait qu'en cas de nécessité, il suffit de surcharger cette méthode dans votre classe.
Cependant, en choisissant cette option, vous vous exposez à des problèmes de non portabilité car si votre widget hérité fonctionne sur une plate-forme, il peut ne pas fonctionner sur une autre. Donc, à vous de savoir si ça vaut le coup de passer par l'héritage.
L'utilisation de ce mécanisme est à réserver pour faire du BugFix, sans attendre que cela soit intégré à la distribution officielle de SWT. Il ne faut pas s'en servir en revanche pour ajouter des fonctionnalités.
En clair, pas d'héritage de widget en SWT. La solution est d'utiliser la composition.
La présence des librairies natives de SWT impose de signer vos jar afin de pouvoir sortir de la Sandbox de Java Web Start.
Pour cela, il faut préparer un jar de votre application (myApp.jar), un jar avec les librairies natives (swt_win32.dll sous Windows) que l'on va nommer swt-native.jar et avoir sous la main swt.jar.
- Pour générer votre propre certificat, en ligne de commande tapez la commande : keytool -genkey -keystore myKeyStore -alias myKey où
- myKeyStore est le nom que vous voulez pour votre keyStore
- myKey est le nom que vous voulez pour votre clé
Répondez aux questions en n'oubliant pas le mot de passe et repondez yes à la dernière question. - Ensuite, tapez la commande : keytool -selfcert -alias myKey -keystore myKeyStore (attention au mot de passe)
- Et pour finir
jarsigner.exe -keystore myKeyStore -verbose -certs swt.jar myKey
jarsigner.exe -keystore myKeyStore -verbose -certs swt-native.jar myKey
jarsigner.exe -keystore myKeyStore -verbose -certs myApp.jar myKey - Faire également de même avec toutes vos librairies (jface.jar, ...).
Puis comme fichier .jnlp
Code xml : | Sélectionner tout |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 | <?xml version="1.0" encoding="utf-8"?> <jnlp spec="1.0+" codebase="http://www.domaine.com/application" href="myApp.jnlp"> <information> <title>myApp</title> <vendor>Lunatix corporation inc</vendor> <homepage href="http://www.domaine.com/"/> <description>myApp</description> <description kind="short">une application de test</description> </information> <security> <all-permissions/> </security> <resources> <j2se version="1.4+"/> <jar href="myApp.jar"/> <jar href="jface.jar"/> <jar href="forms.jar"/> <nativelib href="swt-native.jar"/> </resources> <resources os="Windows"> <jar href="swt.jar"/> </resources> <application-desc main-class="com.domaine.myApp.MyApp" /> </jnlp> |
Pour une version plus détaillée, lisez l'article lfe.developpez.com/Java/SWT/WebStart/ de LFE .
Il n'y a pas de calendrier ni de widget dédié aux dates dans SWT. Il faut donc utiliser des librairies supplémentaires
SWTCalendar
SWT DatePicker
Depuis la version 3.3, un composant de sélection de date/temps a été intégré au jeu de composants standard de SWT. C'est le widget DateTime
Voici un exemple de son utilisation :
Code java : | Sélectionner tout |
1 2 | DateTime calendar = new DateTime (shell, SWT.CALENDAR); DateTime time = new DateTime (shell, SWT.TIME); |
Suite à un clic sur la croix de fermeture d'une fenêtre (Shell), celle-ci est "disposée" et par conséquent fermée. La fenêtre n'est pas simplement rendue invisible, ses ressources sont effectivement libérées, via un appel implicite de la méthode dispose().
Pour empêcher de "disposer" une fenêtre à sa fermeture, il suffit de placer un écouteur sur l'événement ShellEvent et traiter la méthode shellClosed(). L'événement ShellEvent véhicule un flag appelé doit dont le rôle est d'indiquer si l'opération en cours (fermeture, iconification, ...) doit être achevée ou pas. Dans notre cas, il suffit de mettre le flag à faux.
Par ailleurs, on rend la fenêtre Shell invisible en appelant sa méthode setVisible() avec false et on préserve ainsi l'instance de la fenêtre, pour notamment la faire réapparaître lorsque nécessaire.
Code java : | Sélectionner tout |
1 2 3 4 5 6 7 8 9 10 11 12 | shell.addShellListener(new ShellAdapter() { /** * @see org.eclipse.swt.events.ShellAdapter#shellClosed(org.eclipse.swt.events.ShellEvent) */ @Override public void shellClosed(ShellEvent event) { // On neutralise l'événement event.doit = false; // On rend la fenêtre invisible ((Shell) event.getSource()).setVisible(false); } }); |
Proposer une nouvelle réponse sur la FAQ
Ce n'est pas l'endroit pour poser des questions, allez plutôt sur le forum de la rubrique pour çaLes sources présentées sur cette page sont libres de droits et vous pouvez les utiliser à votre convenance. Par contre, la page de présentation constitue une œuvre intellectuelle protégée par les droits d'auteur. Copyright © 2024 Developpez Developpez LLC. Tous droits réservés Developpez LLC. Aucune reproduction, même partielle, ne peut être faite de ce site et de l'ensemble de son contenu : textes, documents et images sans l'autorisation expresse de Developpez LLC. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts.