Door het org.eclipse.jface.resource-pakket worden de klassen gedefinieerd die ervoor zorgen dat de plugins de gebruikersinterfaceresources, bijvoorbeeld lettertypen en pictogrammen, kunnen beheren.
Veel van de workbenchextensiepunten bieden de mogelijkheid aan plugins pictogrammen te leveren die kunnen worden gebruikt voor het afbeelden van hun bijdragen aan de workbench. Omdat GUI-besturingssystemen een beperkt aantal afbeeldingen of lettertypen tegelijk in het geheugen ondersteunen, moeten de gebruikersinterfaceresources van een plugin zorgvuldig worden beheerd en incidenteel worden gedeeld tussen de widgets.
Verschillende verwijzingen naar pictogrammen zijn al besproken in de toolplugin Readme. Een aantal van de pictogrammen worden opgegeven in de markup plugin.xml.
<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>
Ook is vluchtig gekeken naar codering die afbeeldingen beschrijft. Het onderstaande is afkomstig uit ReadmeEditorActionBarContributor van de Readme-tool.
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 levert de ondersteunende basisklassen die het mogelijk maken voor plugins om pictogrammen en lettertypen te beheren zonder dat hoeft te worden gelet op wanneer de bijbehorende grafische objecten van het platform worden gemaakt en vernietigd. Deze ondersteunende klassen worden direct door de plugins gebruikt, zoals hierboven getoond, of indirect, als de workbench deze klassen gebruikt om afbeeldingen te verkrijgen die worden beschreven in de extensiepuntmarkup.
De SWT-Image-klasse geeft een afbeelding weer vanuit het perspectief van het besturingssysteem. Omdat de meeste GUI-besturingssystemen worden beperkt in het aantal afbeeldingen dat tegelijk kan worden geopend, moeten deze zorgvuldig worden gemaakt door de plugins en moet erop worden gelet dat deze op de juiste wijze worden verwijderd wanneer de afbeeldingen niet meer nodig zijn. Door gebruik te maken van de JFace-klassen ImageDescriptor en ImageRegistry in plaats van de SWT-afbeelding, kunnen de plugins vaak vermijden dat deze afbeeldingen direct moeten worden gemaakt, beheerd en verwijderd.
De ImageDescriptor-klasse kan worden gebruikt als lichtgewichtbeschrijving van een afbeelding. Hierin wordt alles opgegeven dat nodig is voor het maken van een afbeelding, bijvoorbeeld de URL of de bestandsnaam waar de afbeelding kan worden opgehaald. ImageDescriptors wijzen de werkelijke platformafbeelding niet toe, tenzij dit specifiek wordt aangevraagd met de createImage()-methode.
Afbeeldingsdescriptors vormen de beste strategie wanneer de code zodanig is gestructureerd dat deze alle pictogrammen op een plaats definieert en deze naar behoefte toewijst. Afbeeldingsdescriptors kunnen op elk moment worden gemaakt waarbij de besturingssysteemresources buiten beschouwing kunnen worden gelaten, zodat deze afbeeldingsdescriptors alle in initialisatiecode kunnen worden gemaakt.
De klasse ImageRegistry wordt gebruikt om een lijst bij te houden van benoemde afbeeldingen. De clients kunnen afbeeldingsdescriptors of SWT-afbeeldingen direct aan de lijst toevoegen. Wanneer een afbeelding op naam van het register wordt aangevraagd, zendt het register de afbeelding terug als deze is gemaakt, of maakt er een op basis van de descriptor. Op deze manier kunnen clients van het register de afbeeldingen gemeenschappelijk gebruiken.
De afbeeldingen die worden toegevoegd aan of opgehaald van het register, mogen niet door een client worden verwijderd. Het register is verantwoordelijk voor het verwijderen van de afbeelding omdat de afbeeldingen worden gedeeld door verschillende clients. Het register verwijdert de afbeeldingen als het GUI-systeem van het platform wordt afgesloten.
Waar mogelijk geeft u het pictogram op voor de gebruikersinterface-objecten van uw plugin in het bestand plugin.xml. Veel van de workbenchextensiepunten bevatten configuratieparameters voor een pictogrambestand. Door uw pictogrammen in uw extensiebijdrage te definiëren in plugin.xml, laat u de strategie voor afbeeldingsbeheer op het platform. Omdat de pictogrammen in uw plugindirectory blijven, kunt u vanaf één plaats de pictogrammen opgeven en de bestanden beheren.
U gebruikt de andere modellen alleen als u het pictogram niet kunt opgeven als onderdeel van uw extensiebijdrage.
Een afbeelding expliciet maken is de beste strategie wanneer de afbeelding niet regelmatig wordt gebruikt en niet wordt gedeeld. De afbeelding kan direct worden gemaakt in SWT en na gebruik weer worden verwijderd.
De afbeeldingen kunnen ook expliciet worden gemaakt door een ImageDescriptor te gebruiken en de methode createImage() op te roepen. Net als in het eerste geval, moet de methode dispose() voor de afbeelding worden opgeroepen nadat de afbeelding niet meer nodig is. Als een dialoogvenster bijvoorbeeld een afbeelding maakt wanneer het geopend wordt, moet de afbeelding bij sluiten worden verwijderd.
Wanneer een afbeelding regelmatig wordt gebruikt in een plugin en door veel verschillende objecten in de gebruikersinterface wordt gedeeld, is het handig de afbeeldingsdescriptor te registreren in een ImageRegistry. De afbeeldingen in het register worden met ieder object gedeeld dat een afbeelding opvraagt met dezelfde naam. U moet geen afbeeldingen uit het register verwijderen omdat deze met andere objecten worden gedeeld.
Wanneer de afbeelding regelmatig wordt gebruikt, misschien gedurende de levensduur van de plugin, en wordt gedeeld met veel objecten, is de beste strategie het toevoegen van een afbeelding aan het afbeeldingsregister. Het nadeel van het gebruik van het register is dat de afbeeldingen in het register niet worden verwijderd voordat het GUI-systeem wordt afgesloten. Omdat er een limiet geldt voor het aantal platformafbeeldingen (SWT) dat tegelijkertijd geopend kan zijn, moet erop worden gelet dat de plugins niet te veel pictogrammen registreren in een register.
De klasse AbstractUIPlugin bevat een protocol voor het maken van een afbeeldingsregister voor de hele plugin.
Wanneer een pictogram regelmatig wordt gebruikt voor het weergeven van items in een bepaalde viewer, kan het met behulp van een labelprovider worden gedeeld met vergelijkbare items in de viewer. Omdat een labelprovider verantwoordelijk is voor het terugzenden van een afbeelding voor een object in een viewer, kan deze het maken van de afbeelding en het delen van afbeeldingen tussen de objecten in de viewer beheren.
De labelprovider kan een van de bovenstaande technieken gebruiken voor het produceren van een afbeelding. Als u de verschillende implementaties van getImage() doorbladert in de LabelProvider-subklassen, ziet u verschillende technieken, inclusief het in cache opslaan van een enkel pictogram voor objecten en het onderhouden van een tabel met afbeeldingen op type. De afbeeldingen die zijn gemaakt door een labelprovider moeten worden verwijderd in de dispose() methode van de provider, die wordt aangeroepen als de viewer wordt verwijderd.
Het gebruiken van een labelprovider is een goede middenweg tussen het expliciet maken van een afbeelding en het afbeeldingsregister. Dit biedt ondersteuning voor het delen van pictogrammen net als het afbeeldingsregister, maar houdt het beheer over het maken en verwijderen van de feitelijke afbeelding.
Wanneer een plugin wordt afgestemd, wordt in het algemeen geëxperimenteerd met al deze verschillende modellen voor het maken van afbeeldingen. Het kan handig zijn het nemen van beslissingen over het maken van afbeeldingen in een aparte klasse onder te brengen en alle clients op te dragen de klasse te gebruiken voor het ophalen van alle afbeeldingen. Op deze manier kan de maakvolgorde worden afgesteld zodat deze de werkelijke prestatiekenmerken van de plugin weerspiegelt.
De ResourceManager-klasse wordt gebruikt om een toewijzing van ImageDescriptors naar Images te bewaren, zodat een afbeelding opnieuw kan worden gebruikt door ernaar te verwijzen via de afbeeldingsdescriptor. Wanneer een afbeelding op descriptor uit het register wordt aangevraagd, zendt het register de afbeelding terug als deze is gemaakt, of maakt er een op basis van de descriptor. Op deze manier kunnen clients van het register de afbeeldingen gemeenschappelijk gebruiken.
De ResourceManager op het hoogste niveau is een DeviceResourceManager die is gemaakt op een weergave. De ResourceManager die wordt gedefinieerd door JFaceResources.getResources() is een DeviceResourceManager en kan worden gebruikt als de ResourceManager van het bovenste niveau. Als u een ResourceManager nodig hebt met een kortere levenscyclus dan de DeviceResourceManager kunt u een LocalResourceManager maken als onderliggend item en deze verwijderen als u deze niet meer nodig hebt.
Een DeviceResourceManager wordt verwijderd wanneer de Weergave die is gebruikt om deze te maken, wordt verwijderd, dus hiervoor is geen speciale beheercode vereist.
De afbeeldingen die zijn toegevoegd aan of opgehaald uit de manager, mogen niet door een client worden verwijderd. De manager is verantwoordelijk voor het verwijderen van afbeeldingen omdat de afbeeldingen worden gedeeld door verschillende clients. Het register verwijdert de afbeeldingen wanneer de ResourceManager die deze bewaart, wordt verwijderd.
Lettertypen vormen een andere beperkte resource van de platformbesturingssystemen. De onderwerpen maken en verwijderen, zijn voor lettertypen dezelfde als voor afbeeldingen, waarbij een vergelijkbare wisselwerking bestaat tussen snelheid en ruimte. In het algemeen worden lettertypen in SWT toegewezen door een lettertype op te vragen met een platformafhankelijke lettertypenaam.
De FontRegistry-klasse onderhoudt een tabel met lettertypen op naam. Deze beheert het toewijzen en verwijderen van het lettertype.
In het algemeen moet vermeden worden dat plugins lettertypen toewijzen of lettertypen beschrijven met platformspecifieke namen. Hoewel het lettertyperegister intern wordt gebruikt in JFace, wordt dit gewoonlijk niet gebruikt door plugins. De JFaceResources-klasse moet worden gebruikt om toegang te krijgen tot algemene lettertypen.
Gewoonlijk kunnen gebruikers hun voorkeuren voor de lettertypen van de toepassing opgeven op een voorkeurenpagina. In deze gevallen moet de FontFieldEditor worden gebruikt om de lettertypenaam van de gebruiker op te halen en kan het FontRegistry worden gebruikt om het lettertype te bewaren. De FontFieldEditor wordt alleen gebruikt in de voorkeurenpagina's.
De klasse JFaceResources beheert de toegang tot gemeenschappelijke lettertypen en afbeeldingen van het platform. Deze onderhoudt een intern lettertype- en afbeeldingsregister zodat clients de benoemde lettertypen en afbeeldingen kunnen delen.
Er zijn vele technieken in de workbench en in andere plugins die worden gebruikt voor het delen van de afbeeldingen waar dit nodig is. Het afbeeldingsregister JFaceResources wordt niet in de gehele workbench- en plugincode gebruikt.
Het gebruik van lettertypen is veel eenvoudiger. De workbench en de meeste plugins gebruiken de JFaceResources-klasse om lettertypen aan te vragen met hun logische naam. De methoden getDialogFont() en getDefaultFont() worden geleverd zodat de plugins de verwachte lettertypen kunnen gebruiken in hun gebruikersinterface.