Standard Widget Toolkit

SWT (Standard Widget Toolkit) est un toolkit destiné aux développeurs Java qui fournit une API transférable et une intégration étroite à la plateforme de l'interface graphique du système d'exploitation natif sous-jacent.

De nombreuses tâches de programmation de bas niveau de l'interface utilisateur sont traitées dans des couches supérieures de la plateforme Eclipse. Par exemple, la marque plugin.xml pour les contributions de l'interface utilisateur indique le contenu des menus et barres d'outils sans recourir à la programmation SWT. Par ailleurs, les afficheurs et actions JFace offrent des implémentations pour les interactions courantes entre applications et widgets. Cependant, la connaissance de l'architecture et de la philosophie de conception SWT sous-jacente est importante pour comprendre comment le reste de la plateforme fonctionne.

Portabilité et intégration de la plateforme

Une question courante concernant la conception d'un toolkit de widgets est la tension qui existe entre les toolkits transférables et l'intégration de la plateforme. Java AWT (Abstract Window Toolkit) fournit des widgets intégrés à la plateforme pour d'autres de niveau inférieur, tels que listes, textes ou boutons. En revanche, il n'offre pas l'accès à des composants de niveau supérieur, tels que des arborescences ou du texte enrichi. Les développeurs d'application se retrouvent alors dans une situation de "plus petit dénominateur commun" où ils ne peuvent utiliser que les widgets disponibles sur toutes les plateformes.

Le module de développement Swing tente de résoudre ce problème en fournissant des implémentations non natives de widgets de niveau supérieur, tels que des arborescences, des tables et du texte. Ceci fournit un grand nombre de fonctionnalités, mais les applications développées en code Swing restent en dehors, du fait qu'elles sont différentes. Les niveaux d'émulation de présentation de la plateforme permettent aux applications de ressembler bien plus à la plateforme, mais l'interaction de l'utilisateur est suffisamment différente pour être remarquée. Ceci rend difficile l'utilisation des toolkits émulés pour générer des applications qui soient compétitives avec les applications prêtes à l'emploi, développées spécialement pour la plateforme d'un système d'exploitation spécifique.

SWT tente de résoudre ce problème en définissant une API transférable commune, fournie sur toutes les plateformes supportées, et en l'implémentant sur chaque plateforme, chaque fois que possible à l'aide de widgets natifs. Ceci permet au toolkit de refléter immédiatement les modifications apportées à la présentation de l'interface graphique du système d'exploitation sous-jacent, tout en maintenant un modèle de programmation cohérent sur toutes les plateformes.

Le problème du "plus petit dénominateur commun" est résolu par SWT de diverses façons :

Cohérence avec la plateforme

L'intégration de la plateforme n'est pas seulement une question d'apparence. Une intégration étroite inclut la capacité d'interagir avec des fonctions du bureau natif, telles que glisser-déposer, l'intégration avec les applications du bureau du système d'exploitation et l'utilisation des composants développés avec les modèles de composant du système d'exploitation, tel que Win32 ActiveX.

Windows uniquementLe support d'ActiveX dans SWT est abordé dans l'article ActiveX Support in SWT.

La cohérence est également atteinte dans le code lui-même en fournissant une implémentation qui semble familière au développeur du système d'exploitation natif. Plutôt que de masquer les différences du système d'exploitation dans le code C natif ou de tenter de générer des couches transférables et non transférables dans l'implémentation Java, SWT fournit des implémentations isolées et distinctes en Java pour chaque plateforme.

L'une des règles d'implémentation importantes est que les natifs en C mappent un sur un les appels au système d'exploitation. Un programmeur Windows reconnaît immédiatement l'implémentation du toolkit SWT sous Windows, car il utilise les natifs qui mappent directement sur les appels système utilisés en C. Rien de la "magie de la plateforme" n'est masqué en code C. Un développeur de plateforme peut voir le code et savoir exactement quels appels de la plateforme sont exécutés par le toolkit. Ceci simplifie considérablement les opérations de débogage. En cas d'incident lors de l'appel d'une méthode native, l'appel de l'API de la plateforme avec les mêmes paramètres du code C connaîtra le même échec. (Ce point est abordé en détail dans l'article SWT Implementation Strategy for Java Natives.)

Copyright IBM Corporation and others 2000, 2003.