Für die Erstellung von komplexen Benutzerschnittstellen steht eine äußerst umfangreiche Gruppe von Klassen und Schnittstellen zur Verfügung. Glücklicherweise müssen Sie nicht alle von ihnen verstehen, um ein einfaches Plug-in zu erstellen. Zunächst werden einige Konzepte vorgestellt, die in der Workbench-Benutzerschnittstelle erkennbar sind, sowie die entsprechende Struktur, die diesen Konzepten zu Grunde liegt.
Der Begriff Workbench wurde bislang als allgemeine Bezeichnung für "das Fenster, das beim Starten der Plattform geöffnet wird" verwendet. Als Einstieg in dieses Thema werden im Folgenden einige der optischen Komponenten genauer beschrieben, aus denen die Workbench besteht.
Wenn der Begriff "Workbench" im weiteren Verlauf dieser Erläuterungen verwendet wird, bezeichnet er das Workbench-Fenster (IWorkbenchWindow). Das Workbench-Fenster ist das Fenster der höchsten Ebene in einer Workbench. Es ist der Frame, der die Menüleiste, die Symbolleiste, die Statuszeile, die Direktaufrufleiste und die Seiten enthält. Im Allgemeinen müssen Sie das Workbench-Fenster nicht programmieren. Sie müssen lediglich wissen, dass es vorhanden ist.
Hinweis: Über die Optionen Perspektive > Öffnen können Sie mehrere Workbench-Fenster öffnen. In der Standardeinstellung werden neue Perspektiven im gleichen Workbench-Fenster geöffnet. Es stehen jedoch andere Optionen zur Verfügung (weitere Details finden Sie auf der Benutzervorgabenseite der Workbench). Jedes Workbench-Fenster ist eine abgeschlossene Umgebung aus Editoren und Sichten. Daher wird die folgende Erläuterung anhand eines einzelnen Workbench-Fensters verdeutlicht.
Aus Sicht des Benutzers enthält eine Workbench Sichten und Editoren. Es gibt wenige weitere Klassen, mit denen das Workbench-Fenster implementiert wird.
Innerhalb des Workbench-Fensters sehen Sie eine oder mehrere Seiten (IWorkbenchPage), die wiederum Komponenten enthalten. Seiten sind ein Implementierungsmechanismus, mit dem Komponenten gruppiert werden können. Normalerweise müssen Sie keine Programmierung für die Seite vornehmen. Im Kontext von Programmierung und Debug müssen Sie jedoch mit Seiten arbeiten.
Hinweis: Seiten werden bei der Implementierung von Perspektiven verwendet. Durch sie können Workbench-Komponenten in externe Container versetzt werden, ohne dass es von Bedeutung ist, ob die Perspektive im gleichen Workbench-Fenster oder in einem neuen Workbench-Fenster geöffnet wird.
Mit Sichten und Editoren beginnt der Übergang von Implementierungsdetails zu einigen allgemeinen Aspekten der Plug-in-Programmierung. Wenn Sie eine optische Komponente zur Workbench hinzufügen, müssen Sie festlegen, ob Sie diese in einer Sicht oder in einem Editor implementieren wollen. Diese Entscheidung basiert auf den folgenden Punkten:
Eine Sicht oder ein Editor wird jedoch immer gemäß einem allgemeinen Lebenszyklus erstellt.
Sie implementieren eine Methode createPartControl, um die SWT-Fensterobjekte zu erstellen, mit denen Ihre optische Komponente dargestellt werden soll. Sie müssen festlegen, welche Fensterobjekte verwendet werden, und alle zugehörigen Benutzerschnittstellenressourcen zuordnen, die zum Anzeigen der Sicht oder des Editors benötigt werden.
Wenn Ihre Sicht oder Ihr Editor fokussiert wird, empfangen Sie eine Benachrichtigung setFocus, damit der Fokus auf das korrekte Fensterobjekt gesetzt werden kann.
Beim Schließen der Sicht bzw. des Editors empfangen Sie eine Nachricht dispose, die angibt, dass die Sicht/der Editor geschlossen wird. An diesem Punkt wurden die in der Methode createPartControl zugeordneten Fensterobjekte bereits freigegeben. Sie selbst müssen jedoch noch alle Grafikressourcen (z. B. Cursor, Symbole oder Schriftarten) freigeben, die Sie beim Erstellen der Fensterobjekte oder als Reaktion auf Fensterobjektereignisse zugeordnet haben.
Während dieses Lebenszyklus werden auf der enthaltenden Workbench-Seite Ereignisse ausgelöst, um die betreffenden Komponenten vom Öffnen, Aktivieren, Inaktivieren und Schließen der Sichten und Editoren zu unterrichten.
Dies kann so einfach sein, wie es sich anhört, und ist auch der Grund für die hervorragenden Einsatzmöglichkeiten von Sichten und Editoren. Eigentlich sind sie nur eine Art Behälter für Fensterobjekte und können so einfach oder komplex sein, wie es Ihren Anforderungen entspricht. Die denkbar einfachste Sicht haben Sie bereits bei der Erstellung der Sicht "Hello World" kennen gelernt. Da Sie jetzt über umfangreichere Kenntnisse verfügen, wird das Beispiel noch einmal wiederholt:
package org.eclipse.examples.helloworld;
import org.eclipse.swt.widgets.Composite;
import org.eclipse.swt.widgets.Label;
import org.eclipse.swt.SWT;
import org.eclipse.ui.part.ViewPart;
public class HelloWorldView extends ViewPart {
Label label;
public HelloWorldView() {
}
public void createPartControl(Composite parent) {
label = new Label(parent, SWT.WRAP);
label.setText("Hello World");
}
public void setFocus() {
// Mein Fensterobjekt
fokussieren. Bei einem Anzeigenelement ist dies nicht sehr
// sinnvoll, bei einer komplexeren Gruppe von Fensterobjekten
// würden Sie jedoch entscheiden, welches Objekt fokussiert werden soll.
}
}
Sie können feststellen, dass eine Methode dispose() nicht implementiert werden musste, weil lediglich in der Methode createPartControl(parent) ein Anzeigenelement erstellt wurde. Wären etwa Benutzerschnittstellenressourcen wie Images oder Schriftarten zugeordnet worden, hätten diese freigegeben werden müssen. Da die Klasse ViewPart erweitert wurde, wird die Implementierung von "do nothing" aus dispose() übernommen.