Das Paket org.eclipse.jface.resource definiert Klassen, die Plug-ins bei der Verwaltung von Benutzerschnittstellenressourcen wie zum Beispiel Schriftarten und Symbolen unterstützen.
An vielen Erweiterungspunkten der Workbench können Plug-ins Symbole angeben, die zur Darstellung der entsprechenden Ergänzung in der Workbench verwendet werden können. Da GUI-Betriebssysteme gleichzeitig nur eine begrenzte Anzahl von Symbolen oder Schriftarten im Speicher unterstützen, müssen die Benutzerschnittstellenressourcen eines Plug-ins sorgfältig verwaltet und manchmal von Fensterobjekten gemeinsam benutzt werden.
Einige Verweise auf Symbole haben Sie bereits im Plug-in des Tools für Readme-Dateien kennen gelernt. Manche dieser Symbole sind in der Formatierungsdatei plugin.xml angegeben.
<extension point="org.eclipse.ui.views"> <category id="org.eclipse.ui.examples.readmetool" name="%Views.category"> </category> <view id="org.eclipse.ui.examples.readmetool.views.SectionsView" name="%Views.ReadmeSections" icon="icons/view16/sections.png" category="org.eclipse.ui.examples.readmetool" class="org.eclipse.ui.examples.readmetool.ReadmeSectionsView"> </view> </extension>
Außerdem haben Sie bereits Code kennen gelernt, der Images während der Verarbeitung beschreibt. Das folgende Beispiel stammt aus der Klasse ReadmeEditorActionBarContributor im Tool für Readme-Dateien.
public ReadmeEditorActionBarContributor() { ... action1 = new EditorAction(MessageUtil.getString("Editor_Action1")); action1.setToolTipText(MessageUtil.getString("Readme_Editor_Action1")); action1.setDisabledImageDescriptor(ReadmeImages.EDITOR_ACTION1_IMAGE_DISABLE); action1.setImageDescriptor(ReadmeImages.EDITOR_ACTION1_IMAGE_ENABLE); ...
JFace stellt die Klassen für die Basisunterstützung bereit, mit deren Hilfe Plug-ins Symbole und Schriftarten verwalten können, ohne Rücksicht auf das Erstellen und Löschen der Grafikobjekte der entsprechenden Plattform nehmen zu müssen. Diese Unterstützungsklassen werden, wie oben gezeigt, durch Plug-ins direkt oder aber indirekt verwendet, wenn die Workbench diese Klassen einsetzt, um Images abzurufen, die in der Definition eines Erweiterungspunkts beschrieben sind.
Die SWT-Klasse Image stellt ein Image aus der Perspektive des Betriebssystems dar. Da bei den meisten GUI-Betriebssystemen gleichzeitig nur eine begrenzte Anzahl von Images geöffnet sein kann, sollten diese in Plug-ins sorgfältig erstellt werden. Außerdem müssen sie sicherstellen, dass die Images ordnungsgemäß entfernt werden, sobald sie nicht mehr benötigt werden. Wenn Sie die JFace-Klassen ImageDescriptor und ImageRegistry anstelle eines SWT-Images verwenden, können Plug-ins die direkte Erstellung, die direkte Verwaltung und das direkte Entfernen dieser Images generell vermeiden.
Die Klasse ImageDescriptor kann als eine Art einfache Beschreibung eines Images verwendet werden. Sie gibt alle Informationen an, die zur Erstellung eines Images benötigt werden, beispielsweise die URL oder den Dateinamen, aus der/dem das Image abgerufen werden kann. Klassen ImageDescriptors ordnen nur dann tatsächlich ein Plattform-Image zu, wenn dies durch die Methode createImage() explizit angefordert wird.
Image-Deskriptoren sind die beste Strategie, wenn Ihr Code so strukturiert ist, dass alle Symbole an einer Stelle definiert sind und bei Bedarf zugeordnet werden. Image-Deskriptoren können jederzeit ohne Rücksicht auf die Ressourcen des Betriebssystems erstellt werden. Daher können sie ohne weiteres vollständig im Initialisierungscode erstellt werden.
Mit der Klasse ImageRegistry wird eine Liste der benannten Images beibehalten. Clients können Image-Deskriptoren oder SWT-Images direkt zur Liste hinzufügen. Sobald ein Image über seinen Namen aus der Registrierung angefordert wird, gibt die Registrierung das Image zurück, als ob es erstellt worden wäre, oder erstellt ein Image aus dem Deskriptor. Auf diese Weise können Clients der Registrierung Images gemeinsam benutzen.
Images, die zur Registrierung hinzugefügt oder aus ihr abgerufen werden, dürfen nicht durch Clients entfernt werden. Zuständig für das Entfernen des Images ist die Registrierung, da die Images von mehreren Clients gemeinsam benutzt werden. Die Registrierung entfernt die Images, wenn das GUI-System der Plattform beendet wird.
Wann immer dies möglich ist, sollten Sie das Symbol für die Benutzerschnittstellenobjekte Ihres Plug-ins in der Datei plugin.xml angeben. Viele Erweiterungspunkte der Workbench enthalten Konfigurationsparameter für eine Symboldatei. Indem Sie Ihre Symbole in der Datei "plugin.xml" der Erweiterungsergänzung definieren, überlassen Sie es der Plattform, eine Strategie zur Image-Verwaltung auszuwählen. Da die Symbole normalerweise im Verzeichnis des Plug-ins aufbewahrt werden, können Sie auf diese Weise die Symbole an einer einheitlichen Stelle angeben, an der Sie auch die Dateien verwalten.
Die anderen Muster sollten nur dann verwendet werden, wenn das Symbol nicht im Rahmen der Erweiterungsergänzung angegeben werden kann.
Das explizite Erstellen eines Images ist die beste Strategie, wenn das Image nur selten und nicht gemeinsam benutzt wird. Das Image kann direkt in SWT erstellt und nach seiner Verwendung entfernt werden.
Images können auch durch die Verwendung einer Klasse ImageDescriptor und durch Aufrufen der Methode createImage() explizit erstellt werden. Wie im ersten Fall muss die Methode "dispose()" für das Image aufgerufen werden, sobald es nicht mehr benötigt wird. Erstellt beispielsweise ein Dialog ein Image, wenn er geöffnet wird, sollte das Image beim Schließen des Dialogs von ihm freigegeben werden.
Wenn ein Image in einem Plug-in häufig eingesetzt und von vielen verschiedenen Objekten in der Benutzerschnittstelle gemeinsam benutzt wird, ist es sinnvoll, den Image-Deskriptor mit einer Klasse ImageRegistry zu registrieren. Die Images in der Registrierung werden mit allen Objekten gemeinsam benutzt, die das Image über denselben Namen abfragen. Sie dürfen keine Images aus der Registrierung entfernen, da sie mit anderen Objekten gemeinsam benutzt werden.
Das Hinzufügen eines Images zur Image-Registrierung ist dann die beste Strategie, wenn das Image häufig - möglicherweise während der gesamten Lebensdauer eines Plug-ins - verwendet und durch viele Objekte gemeinsam benutzt wird. Die Verwendung der Registrierung hat allerdings den Nachteil, dass Images aus der Registrierung erst dann entfernt werden, wenn das GUI-System beendet wird. Da gleichzeitig nur eine begrenzte Anzahl von Plattform-Images (SWT-Images) geöffnet sein können, sollten Plug-ins nicht zu viele Symbole in einer Registrierung registrieren.
Die Klasse AbstractUIPlugin enthält ein Protokoll zur Erstellung einer Plug-in-weiten Image-Registrierung.
Wenn ein Symbol häufig dazu verwendet wird, Elemente in einer bestimmten Anzeigefunktion anzuzeigen, kann es über eine Funktion zur Bereitstellung von Bezeichnungen von ähnlichen Sichten in der Anzeigefunktion gemeinsam benutzt werden. Da eine solche Funktion dafür zuständig ist, für jedes Objekt in einer Anzeigefunktion ein Image zurückzugeben, kann sie die Erstellung des Images und die gemeinsame Benutzung des Images für alle Objekte in der Anzeigefunktion steuern.
Diese Funktion kann eine beliebige der zuvor definierten Methoden verwenden, um ein Image zu erzeugen. Wenn Sie sich die unterschiedlichen Implementierungen der Methode getImage() in der Unterklasse LabelProvider genauer ansehen, werden Sie eine Vielzahl von Ansätzen bemerken, bei denen auch ein einziges Symbol für Objekte in den Cache gestellt oder eine Tabelle von Abbildern nach Typ verwaltet wird. Images, die durch einen Label-Provider erstellt werden, müssen in der Methode dispose() des Providers freigegeben werden, die aufgerufen wird, wenn die Anzeigefunktion freigegeben wird.
Die Verwendung einer Funktion zum Bereitstellen einer Bezeichnung ein guter Kompromiss zwischen der expliziten Erstellung und der Image-Registrierung. Wie die Image-Registrierung leitet sie die gemeinsame Benutzung von Symbolen weiter, behält jedoch die Steuerung für das Erstellen und Entfernen des tatsächlichen Images bei.
Bei der Feinabstimmung eines Plug-ins wird im allgemeinen mit allen unterschiedlichen Mustern zur Image-Erstellung experimentiert. Es kann hilfreich sein, die Entscheidungsfindung hinsichtlich der Image-Erstellung in einer separaten Klasse zu isolieren und alle Clients anzuweisen, die Klasse zum Abrufen aller Images zu verwenden. Auf diese Weise kann die Erstellungsfolge optimiert und auf die tatsächlichen Leistungskenndaten des Plug-ins abgestimmt werden.
Die Klasse ResourceManager wird verwendet, um eine Zuordnung von 'ImageDescriptors' zu Grafiken beizubehalten, damit eine Grafik wiederverwendet werden kann, indem über seinen Deskriptor darauf verwiesen werden kann. Sobald ein Image über seinen Deskriptor aus der Registrierung angefordert wird, gibt die Registrierung das Image zurück, als ob es erstellt worden wäre, oder erstellt ein Image aus dem Deskriptor. Auf diese Weise können Clients der Registrierung Images gemeinsam benutzen.
Der ResourceManager auf höchster Ebene ist ein DeviceResourceManager, der in einer Anzeige erstellt wird. Der durch JFaceResources.getResources() definierte ResourceManager ist ein 'DeviceResourceManager' und kann als ResourceManager auf höchster Ebene verwendet werden. Wenn Sie einen ResourceManager mit einem kürzeren Lebenszyklus als dem DeviceResourceManager benötigen, können Sie einenLocalResourceManager als untergeordnetes Element erstellen und später wieder löschen, nachdem Sie damit fertig sind.
Ein DeviceResourceManager wird gelöscht, wenn die zu seiner Erstellung verwendete Anzeige gelöscht wird. Somit ist hierfür kein gesonderter Verwaltungscode nötig.
Images, die zum Manager hinzugefügt oder aus ihm abgerufen werden, dürfen nicht durch Clients entfernt werden. Zuständig für das Entfernen des Images ist der Manager, da die Images von mehreren Clients gemeinsam benutzt werden. Die Registrierung entfernt die Images, wenn der ResourceManager,der diese enthält, entfernt wird.
Auch Schriftarten sind bei Plattformbetriebssystemen eine begrenzte Ressource. Die Aspekte für das Erstellen und Entfernen von Images gelten ebenfalls für Schriftarten und erfordern ähnliche Kompromisse hinsichtlich Geschwindigkeit und Speicher. Im Allgemeinen werden Schriftarten in SWT durch die Anforderung einer Schriftart mit einem plattformabhängigen Schriftartnamen zugeordnet.
Die Klasse FontRegistry verwaltet eine Tabelle der Schriftarten nach Namen. Sie verwaltet das Zuordnen und Entfernen der Schriftart.
Plug-ins sollten generell keine Schriftarten mit plattformspezifischen Namen zuordnen oder beschreiben. Die Schriftartregistrierung wird zwar in JFace intern verwendet, von Plug-ins normalerweise jedoch nicht eingesetzt. Für den Zugriff auf allgemeine Schriftarten sollte die Klasse JFaceResources verwendet werden.
Häufig können Benutzer auf einer Benutzervorgabenseite ihre Wünsche für die Schriftarten einer Anwendung angeben. In solchen Fällen sollte mit der Klasse FontFieldEditor der Schriftartname vom Benutzer erhalten werden, und die Schriftart durch die Verwendung einer Klasse FontRegistry beibehalten werden. Die Klasse FontFieldEditor wird ausschließlich auf Benutzervorgabenseiten verwendet.
Die Klasse JFaceResources steuert den Zugriff auf allgemeine Schriftarten und Images der Plattform. Sie verwaltet eine interne Schriftart- und Image-Registrierung, damit Clients Schriftarten und Images gemeinsam benutzen können.
Es gibt viele Mechanismen in der Workbench und in anderen Plug-ins, um Images gemeinsam zu benutzen, wenn dies erforderlich ist. Die Image-Registrierung JFaceResources wird im Workbench- und Plug-in-Code insgesamt nicht sehr häufig verwendet.
Die Verwendung von Schriftarten ist wesentlich einfacher. Die Workbench und die meisten Plug-ins verwenden die Klasse JFaceResources, um Schriftarten über einen logischen Namen anzufordern. Mit verfügbaren Methoden wie getDialogFont() und getDefaultFont() können Plug-ins die erwarteten Schriftarten in ihren Benutzerschnittstellen verwenden.