Standard Widget Toolkit

aus Wikipedia, der freien Enzyklopädie
Zur Navigation springen Zur Suche springen
Standard Widget Toolkit

Eclipse SWT Windows Vista example.png
Beispielanwendung unter Windows Vista
Basisdaten

Maintainer Eclipse Foundation
Entwickler Stephen Northover
Aktuelle Version 4.23
(8. März 2022)
Betriebssystem plattformunabhängig
Programmiersprache Java[1]
Kategorie GUI-Toolkit
Lizenz Eclipse Public License 2.0[2]
www.eclipse.org/swt/

Das Standard Widget Toolkit (SWT) ist ein GUI-Toolkit für die Erstellung grafischer Oberflächen mit Java.

SWT[Bearbeiten | Quelltext bearbeiten]

SWT wurde im Jahr 2001 von IBM für die Entwicklungsumgebung Eclipse entwickelt und wird kontinuierlich gepflegt. SWT nutzt dabei im Gegensatz zu Swing die nativen grafischen Elemente des Betriebssystems – wie das AWT von Sun – und ermöglicht somit die Erstellung von Programmen, die eine Optik vergleichbar mit „nativen“ Programmen aufweisen.

Allerdings leidet SWT auf einigen Nicht-Windows-Plattformen unter Effizienzproblemen, da es viele Merkmale eines Basistoolkits voraussetzt, welche – wenn nicht vorhanden – emuliert werden müssen (z. B. Z-Ordnung auf GTK+). Zudem sind die SWT-Bibliotheken nicht standardmäßig auf dem ausführenden System verfügbar und müssen mit der Anwendung ausgeliefert werden, während Swing Bestandteil der Java-Laufzeitumgebung (Java Runtime Environment, JRE) ist.

Bei SWT werden native Widgets durch dünne Wrapper eingebunden, anstatt Teile der Funktionalität in native Peer-Klassen auszulagern. Wegen der Verwendung dieser Ressourcen werden die SWT-Elemente „schwergewichtig“ genannt, im Gegensatz zu den „leichtgewichtigen“ Komponenten der Swing-Technik, die alle grafischen Elemente selbst erzeugt.

SWT kommt in einer ganzen Reihe von Anwendungen zum Einsatz, beispielsweise Eclipse selbst, Vuze und RSSOwl.

Geschwindigkeit[Bearbeiten | Quelltext bearbeiten]

SWT wurde als reaktionsschnellere und kompaktere Konkurrenz zu Swing entwickelt. Leistungsvergleiche zeigen allerdings, dass SWT nicht schneller als Swing ist und die Resultate stark vom Kontext und der Testumgebung abhängen.[3]

JFace[Bearbeiten | Quelltext bearbeiten]

Das GUI-Toolkit JFace setzt aus den von SWT gelieferten Basiskomponenten komplexere Widgets zusammen und stellt eine Abstraktionsschicht (Viewer) für den Zugriff auf die Komponenten bereit. JFace erleichtert die Entwicklung von Desktop-Anwendungen auf SWT-Basis erheblich. Die wichtigsten Klassen von JFace sind:

  • Viewers zur Verbindung von GUI-Elementen zum Datenmodell
  • Actions zur Entkopplung von GUI-Events und der auszuführenden Aktion
  • Image- und Font-Registries zur Verwaltung von Bild- und Font-Ressourcen
  • Komplexere GUI-Elemente wie Wizards und Dialoge

Mittlerweile gibt es bei JFace einige Abhängigkeiten zu Eclipse-Bibliotheken, so dass neben SWT auch einige JAR-Dateien aus dem Eclipse-Projekt installiert werden müssen. Eclipse ist die wohl bekannteste Anwendung, die JFace einsetzt.

Verfügbare Systeme und Architekturen[Bearbeiten | Quelltext bearbeiten]

1 Seit SWT 3.5. Offenbar nur noch für x86 und x86_64, aber nicht mehr für PowerPC verfügbar.

Literatur[Bearbeiten | Quelltext bearbeiten]

  • Steve Northover, Mike Wilson: SWT: the standard widget toolkit. Addison-Wesley, Boston 2004, ISBN 0-321-25663-8.

Weblinks[Bearbeiten | Quelltext bearbeiten]

Quellen[Bearbeiten | Quelltext bearbeiten]

  1. The swt Open Source Project on Open Hub: Languages Page. In: Open Hub. (abgerufen am 19. Oktober 2018).
  2. git.eclipse.org.
  3. Križnar Igor: SWT Vs. Swing Performance Comparison (PDF) cosylab.com. 3. März 2006. Archiviert vom Original am 4. Juli 2008.  Info: Der Archivlink wurde automatisch eingesetzt und noch nicht geprüft. Bitte prüfe Original- und Archivlink gemäß Anleitung und entferne dann diesen Hinweis.@1@2Vorlage:Webachiv/IABot/cosylib.cosylab.com Abgerufen am 16. September 2009: „Initial expectation before performing this benchmark was to find SWT outperform Swing. This expectation stemmed from greater responsiveness of SWT-based Java applications (e.g., Eclipse IDE) compared to Swing-based applications. However, this expectation could not be quantitatively confirmed.