Pakken org.eclipse.jface.resource definerer klasser, der hjælper plugins med at styre grænsefladeressourcer, f.eks. fonte og ikoner.
Mange af arbejdsbænkens udvidelsespunkter tillader, at plugins leverer ikoner, der bruges til at vise deres leverancer på arbejdsbænken. Da styresystemer med grafiske brugergrænseflader understøtter et begrænset antal billeder eller fonte i hukommelsen på én gang, skal en plugins grænsefladeressourcer styres meget nøjes, og til tider skal de deles mellem elementer.
Der har allerede været flere referencer til ikoner i plugin'en til Readme-værktøjet. Nogle af ikonerne er angivet i plugin.xml-koden.
<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>
Der er også vist kode, der beskriver billeder, som opstår dynamisk. Følgende stammer fra readme-værktøjets ReadmeEditorActionBarContributor.
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 stiller de grundlæggende understøttelsesklasser til rådighed, og disse tillader, at plugins styrer deres egne ikoner og fonte uden at skulle tage hensyn til, hvornår platformens tilsvarende grafikobjekter oprettes og ødelægges. Disse understøttelsesklasser bruges direkte af plugins, som det er vist ovenfor, eller indirekte, når arbejdsbænken bruger klasserne til at hente billeder, der er beskrevet i udvidelsespunktkoden.
SWT Image-klassen repræsenterer et billede fra operativsystemets perspektiv. Da de fleste styresystemer med grafisk grænseflade har en begrænsning for det antal billeder, der kan være åbne på én gang, skal plugins være meget forsigtige under oprettelsen af dem og sikre, at de også skiller sig af med dem, når de er færdige med at bruge dem. Ved at benytte JFace-klasserne ImageDescriptor og ImageRegistry i stedet for SWT-billedet, kan plugins normalt undgå at oprette, styre og slette disse billeder direkte.
ImageDescriptor-klassen kan benyttes som en letvægtsbeskrivelse af et billede. Den angiver alt, hvad der behøves til at oprette et billede, f.eks. URL'en eller filnavnet, hvorfra billedet kan hentes. ImageDescriptors tildeler ikke et egentligt platformbillede, medmindre der anmodes specifikt om det vha. metoden createImage().
Billeddeskriptorer er den bedste strategi at benytte, når koden er struktureret, således at den definerer alle ikonerne på ét sted og tildeler dem efter behov. Billeddeskriptorer kan oprettes til enhver tid uden hensyntagen til operativsystemets ressourcer, hvorfor det er en god ide at oprette dem alle i initialiseringskoden.
ImageRegistry-klassen bruges til at opbevare en liste over navngivne billeder. Klienter kan tilføje billeddeskriptorer eller SWT-billeder direkte til oversigten. Når der anmodes på basis af navnet om et billede fra registreringsdatabasen, returnerer registreringsdatabasen billedet, hvis det er oprettet, eller også opretter den det fra deskriptoren. Registreringsdatabasens klienter kan således dele billederne.
Billeder, der tilføjes eller hentes fra registreringsdatabasen, må ikke kasseres af en klient. Registreringsdatabasen er ansvarlig for bortskaffelsen af billedet, da billederne deles af flere klienter. Registreringsdatabasen kasserer billederne, når platformens brugergrænseflade afsluttes.
Når det er muligt, skal du angive ikonen for plugin'ens grænsefladeobjekt i filen plugin.xml. Mange af arbejdsbænkens udvidelsespunkter indeholder konfigurationsparametre for en ikonfil. Ved at definere ikonerne i udvidelsesleverancen i plugin.xml-filen, overlader du billedstyringsstrategien til platformen. Da ikonerne typisk opbevares i plugin'ens bibliotek, har du mulighed for at angive ikonerne og styre filer et sted fra.
De andre mønstre bør kun overvejes, når du ikke kan angive ikonen som en del af udvidelsesleverancen.
Eksplicit oprettelse af et billede er den bedste strategi, når billedet ikke bruges ofte og ikke deles. Billedet kan oprettes direkte i SWT og kasseres efter brug.
Billeder kan også oprettes eksplicit vha. en ImageDescriptor og start af metoden createImage(). Som i det første tilfælde skal metoden dispose() startes for billedet, når der ikke længere er brug for billedet. Hvis en dialogboks f.eks. opretter et billede, når den åbnes, skal den kassere billedet, når den lukkes.
Når et billede ofte bruges i en plugin og deles på tværs af mange forskellige objekter i grænsefladen, er det nyttigt at registrere billeddeskriptoren med et ImageRegistry. Billederne i registreringsdatabasen deles med alle andre objekter, der forespørger på et billede med det samme navn. Du må ikke kassere nogen af billederne i registreringsdatabasen, da de deles af andre objekter.
At tilføje et billede til billedregistreringsdatabasen er den bedste strategi, når billedet ofte benyttes - måske endda i hele plugin'ens levetid - og deles af mange objekter. Ulempen ved at bruge registreringsdatabasen er, at billeder i registreringsdatabasen først kasseres, når den grafiske brugergrænseflade lukkes. Da det er begrænset, hvor mange SWT-billeder der kan være åbne ad gangen, skal plugins være forsigtige med ikke at registrere for mange ikoner i en registreringsdatabase.
Klassen AbstractUIPlugin indeholder protokol til oprettelse af en pluginbredt billedregistreringsdatabase.
Når en ikon ofte bruges til at vise elementer i en bestemt fremviser, kan den deles blandt lignende elementer i fremviseren vha. en etiketudbyder. Da en etiketudbyder er ansvarlig for at returnere et billede for et objekt i en fremviser, kan den styre oprettelsen af billedet og delingen af billeder på tværs af objekter i fremviseren.
Etiketudbyderen kan bruge alle de tidligere omtalte teknikker til at producere et billede. Hvis du gennemgår de forskellige implementeringer af getImage() i LabelProvider-underklasserne, kan du se en række fremgangsmåder, inkl. caching af en enkelt ikon for objekter og vedligeholdelse af en tabel over billeder efter type. Billeder, der er oprettet af en etiketudbyder, skal kasseres via udbyderens dispose()-metode, som kaldes, når fremviseren kasseres.
At bruge en etiketudbyder er et godt kompromis mellem eksplicit oprettelse og billedregistreringsdatabasen. Det fremmer deling af ikoner på samme måde som billedregistreringsdatabasen, men der er fortsat kontrol over oprettelsen og bortskaffelsen af det faktiske billede.
Når du finjusterer en plugin, er det almindeligt at eksperimentere med alle disse forskellige billedoprettelsesmønstre. Det kan være nyttigt at isolere beslutningen om billedoprettelse i en separat klasse og instruere alle klienter i at bruge klassen til at hente alle billeder. På denne måde kan oprettelsessekvensen justeres til at afspejle plugin'ens egentlige ydeevneegenskaber.
Klassen ResourceManager bruges til at bevare en tilknytning af ImageDescriptors vha. mapping til billeder, hvorved et billede kan genbruges, ved at der refereres til det via billedets deskriptor. Når deskriptoren anmoder om et billede fra registreringsdatabasen, returnerer registreringsdatabasen billedet, hvis det er oprettet, eller også opretter den et fra deskriptoren. Registreringsdatabasens klienter kan således dele billederne.
ResourceManager på øverste niveau er en DeviceResourceManager, som oprettes i en fremviser. ResourceManager, som er defineret af JFaceResources.getResources(), er en DeviceResourceManager og kan bruges som ResourceManager på øverste niveau. Hvis du har brug for en ResourceManager med en kortere livscyklus end DeviceResourceManager, kan du oprette en LocalResourceManager som underordnet element og kassere den, når du ikke længere har brug for den.
En DeviceResourceManager kasseres, når den fremviser, der bruges til at oprette den, kasseres, hvorfor ingen særlig styringskode er nødvendigt.
Billeder, der tilføjes eller hentes fra manageren, må ikke kasseres af en klient. Manageren er ansvarlig for bortskaffelse af billedet, da billederne deles af flere klienter. Registreringsdatabasen kasserer billederne, når den ResourceManager, der opbevarer dem, kasseres.
Fonte er en anden begrænset ressource i platformstyresystemer. Problemerne vedr. oprettelse og bortskaffelse er de samme for fonte som for billeder og kræver samme afvejning mellem hastighed og plads. Som regel allokeres fonte i SWT, ved at der anmodes en om font med et platformafhængigt fontnavn.
Klassen FontRegistry opbevarer en tabel af fonte baseret på navn. Den administrerer allokeringen og bortskaffelsen af fonten.
Generelt bør plugins undgå at allokere fonte eller beskrive font med platformspecifikke navne. Selvom fontregistreringsdatabasen bruges internt i JFace, bruges den normalt ikke af plugins. Klassen JFaceResources bør anvendes til at få adgang til fælles fonte.
Det er meget almindeligt at lade brugere angive deres egne indstillinger for programmets fonte på indstillingssiden. I disse tilfælde skal FontFieldEditor bruges til at hente fontnavnet fra brugeren, og en FontRegistry kan bruges til at beholde fonten. FontFieldEditor bruges kun på indstillingssiderne.
Klassen JFaceResources styrer adgangen til fælles platformfonte og -billeder. Den vedligeholder en intern font- og billedregistreringsdatabase, så klienter kan dele navngivne fonte og billeder.
Der benyttes mange teknikker på arbejdsbænken og andre plugins til at dele billeder, når det er nødvendigt. Billedregistreringsdatabasen JFaceResources benyttes ikke meget på tværs af arbejdsbænkens og plugin'ens kode.
Brug af fonte er meget simplere. Arbejdsbænke og de fleste plugins bruger klassen JFaceResources til at anmode om fonte på basis af det logiske navn. Metoderne getDialogFont() og getDefaultFont() stilles til rådighed, så plugins kan bruge de forventede fonte i deres grænseflader.