SWT inclut de nombreuses fonctions complexes, mais seule une connaissance de base des API du système (widgets, présentations et événements) est nécessaire pour implémenter des applications utiles et puissantes.
Lorsque vous ajoutez des éléments de l'interface utilisateur à l'aide des extensions du plan de travail de la plateforme, la mécanique de démarrage de SWT est traitée pour vous par le plan de travail.
Si vous écrivez intégralement une application SWT (en dehors du plan de travail), vous devez connaître davantage la structure d'application de SWT.
La structure d'une application SWT autonome classique est la suivante :
Création d'un affichage représentant une session SWT.
Création d'un ou plusieurs shells qui servent de fenêtre principale pour l'application.
Création d'autres widgets requis dans le shell.
Initialisation des dimensions et d'autres états nécessaires pour les widgets. Enregistrement des écouteurs pour les événements de widget devant être traités.
Ouverture de la fenêtre shell.
Exécution de la boucle de distribution des événements jusqu'à ce qu'une condition de sortie soit rencontrée (généralement lorsque la fenêtre shell principale est fermée par l'utilisateur).
Disposition de l'affichage.
Le fragment de code ci-dessous est adapté de l'application org.eclipse.swt.examples.helloworld.HelloWorld2. Comme l'application affiche uniquement la chaîne "Hello World", elle n'a pas besoin de s'inscrire dans des événements de widget.
public static void main (String [] args) {
Display display = new Display ();
Shell shell = new Shell (display);
Label label = new Label (shell, SWT.CENTER);
label.setText ("Hello_world");
label.setBounds (shell.getClientArea ());
shell.open ();
while (!shell.isDisposed ()) {
if (!display.readAndDispatch ()) display.sleep ();
}
display.dispose ();
}
L'affichage représente la connexion entre SWT et le système de l'interface graphique de la plateforme sous-jacente. Des écrans sont principalement utilisés pour gérer la boucle d'événements de la plateforme et contrôler la communication entre l'unité d'exécution de l'interface utilisateur et d'autres unités d'exécution. (Pour plus d'informations sur les questions de l'utilisation d'unités d'exécution de l'interface utilisateur, reportez-vous à la section Remarques relatives au traitement multiple.)
Pour la plupart des applications, vous pouvez suivre le schéma utilisé ci-dessus. Vous devez créer un écran avant de créer des fenêtres et le supprimer une fois le shell fermé. Il ne vous est pas nécessaire d'en faire plus, à moins que vous ne conceviez une application multitâches.
Un shell est une "fenêtre" gérée par le gestionnaire de fenêtres de la plateforme du système d'exploitation. Les shells de niveau supérieur sont ceux créés comme enfant de l'affichage. Ces fenêtres sont celles que les utilisateurs déplacent, redimensionnent, réduisent et agrandissent à l'aide de l'application. Les shells secondaires sont ceux qui sont créés en tant qu'enfant d'un autre shell. Ces fenêtres sont généralement utilisées comme fenêtres de boîte de dialogue ou fenêtres transitoires qui existent uniquement dans le contexte d'une autre fenêtre.
Tous les widgets qui ne sont pas des shells de niveau supérieur ont un parent. Les shells de niveau supérieur n'ont pas de parent, mais ils sont tous créés en association avec un affichage spécifique. Vous pouvez y accéder à l'aide de la méthode getDisplay(). Tous les autres widgets sont créés en tant que descendants (directs ou indirects) des shells de niveau supérieur.
Les widgets composites sont des widgets ayant des enfants.
Lorsque vous voyez une fenêtre d'application, vous pouvez la considérer comme une arborescence de widgets ou une hiérarchie, dont la racine est le shell. Selon la complexité de l'application, il peut y avoir un seul enfant du shell, plusieurs enfants ou des niveaux imbriqués de composites avec enfants.
Lorsque votre application crée un widget, SWT crée immédiatement le widget de plateforme sous-jacent. Ceci élimine le besoin de code qui opère différemment selon que le widget du système d'exploitation sous-jacent existe ou non. Il permet également à la majorité des données du widget d'être conservées au niveau de la plateforme plutôt que d'être dupliquées dans le toolkit. Ceci signifie que le concept du cycle de vie d'un widget vu par le toolkit doit respecter les règles du système de l'interface graphique sous-jacent.
La plupart des plateformes des interfaces graphiques vous demandent de spécifier un parent lorsque vous créez un widget. Comme SWT crée un widget de plateforme dès que vous créez un widget de toolkit, le widget parent doit être spécifié dans le constructeur du widget.
Certaines propriétés de widget doivent être définies par le système d'exploitation au moment de la création d'un widget et ne peuvent pas être modifiées par la suite. Par exemple, une liste peut être à sélection unique ou multiple et peut ou ne pas avoir de barre de défilement.
Ces propriétés, appelées styles, doivent être définies dans le constructeur. Tous les constructeurs de widget prennent un argument int qui spécifie OU bit à bit pour tous les styles souhaités. Dans certains cas, un style particulier est considéré comme une option, ce qui signifie qu'il peut ne pas être disponible sur toutes les plateformes, mais sera vivement ignoré par toutes celles qui ne le supportent pas.
Les constantes de style figurent dans la classe SWT en tant que zones statiques publiques. La liste des constantes applicables pour chaque classe de widget figure dans les références des API pour SWT.
Les plateformes de système d'exploitation situées sous SWT nécessitent l'affectation et la libération explicites de ressources du système d'exploitation. Si vous suivez la philosophie de conception SWT qui consiste à refléter la structure d'application de la plateforme dans le toolkit de widgets, SWT vous invite à libérer explicitement des ressources du système d'exploitation que vous avez allouées. Dans SWT, la méthode dispose() est utilisée pour libérer des ressources associées à un objet de toolkit particulier.
La règle de représentation miniature consiste à dire que si vous avez créé l'objet, vous devez le supprimer. Les règles globales suivantes tentent d'expliquer cette philosophie :
Si vous créez un widget ou un objet graphique à l'aide d'un constructeur, vous devez le supprimer manuellement lorsque vous avez terminé de l'utiliser.
Si vous obtenez un widget ou un objet graphique sans l'aide d'un constructeur, vous ne devez pas le supprimer manuellement du fait que vous ne l'avez pas alloué.
Si vous transmettez une référence à votre widget ou un objet graphique à un autre objet, vous devez faire attention à ne pas le supprimer tant qu'il est en cours d'utilisation. (Nous avons vu précédemment cette règle dans la pratique à la section Schémas de plug-in pour l'utilisation des images.)
Lorsque l'utilisateur ferme un shell, le shell et tous ses widgets enfants sont supprimés de manière récursive. Dans ce cas, il ne vous est pas nécessaire de supprimer les widgets. Cependant, vous devez libérer des ressources graphiques attribuées en rapport à ces widgets.
Si vous créez un objet graphique destiné à être utilisé pendant la durée de vie de l'un de vos widgets, vous devez supprimer l'objet graphique lorsque le widget est supprimé. Ceci peut se faire en enregistrant un écouteur de suppression pour votre widget et en libérant l'objet graphique lorsque l'événement dispose est reçu.
Il existe une exception à la règle. Les objets données simples, tels qu'un rectangle et un point, n'utilisent pas de ressources du système d'exploitation. Ils n'ont pas de méthode dispose() et il n'est pas nécessaire de les libérer. Si vous avez un doute, consultez la documentation Java relative à une classe particulière.