Pretty elegant way to provide images in eclipse UI plug-ins

Donnerstag, 8. Juli, 2010 – 17:55

Loading images is an ever-recurring task in Eclipse plug-in development. So I figured out a pretty elegant solution to provide images and image descriptors within my UI plug-ins.

The pro’s about it are:

  • Image paths are used and defined at exactly one place within the plug-in.
  • You have a constant for all of your images
  • Images are handled and disposed by the plug-ins’ registry.
  • Images and image descriptors are registered and created lazyly on demand.
  • Only pre-defined images can be used.
  • Wrong image paths result in an image proxy, this solution never returns a null value.

And the best thing about it is the elegant syntax to get an image or an image descriptor:

Image image = UIImages.FIRST_ICON.getImage();
ImageDescriptor imageDescriptor = UIImages.FIRST_ICON.getImageDescriptor();

So this is how it works:

package de.wendehals.ui.plugin;
 
import org.eclipse.jface.resource.ImageDescriptor;
import org.eclipse.jface.resource.ImageRegistry;
import org.eclipse.swt.graphics.Image;
 
/**
 * This enumeration provides a number of images for the plugin.
 */
public enum UIImages {
 
	FIRST_ICON("icons/first.gif"),
 
	SECOND_ICON("icons/second.gif");
 
        // add more image enumerations here...
 
 
	private final String path;
 
	private UIImages(final String path) {
		this.path = path;
	}
 
 
	/**
	 * Returns an image. Clients do not need to dispose the image, it will be disposed automatically.
	 * 
	 * @return an {@link Image}
	 */
	public Image getImage() {
		final ImageRegistry imageRegistry = UIPlugin.getDefault().getImageRegistry();
		Image image = imageRegistry.get(this.path);
		if (image == null) {
			addImageDescriptor();
			image = imageRegistry.get(this.path);
		}
 
		return image;
	}
 
	/**
	 * Returns an image descriptor.
	 * 
	 * @return an {@link ImageDescriptor}
	 */
	public ImageDescriptor getImageDescriptor() {
		final ImageRegistry imageRegistry = UIPlugin.getDefault().getImageRegistry();
		ImageDescriptor imageDescriptor = imageRegistry.getDescriptor(this.path);
		if (imageDescriptor == null) {
			addImageDescriptor();
			imageDescriptor = imageRegistry.getDescriptor(this.path);
		}
 
		return imageDescriptor;
	}
 
	private void addImageDescriptor() {
		final UIPlugin plugin = UIPlugin.getDefault();
		final ImageDescriptor id = ImageDescriptor.createFromURL(plugin.getBundle().getEntry(this.path));
		plugin.getImageRegistry().put(this.path, id);
	}
 
}

Of course what you need is a plug-in class (here UIPlugin) extending AbstractUIPlugin to provide the image registry. More images can be added by adding a new enumeration value with the image’s path.

Hope, you like it too. Feel free to use it in your UI plug-ins.

Modellvergleich mit EMF Compare – 2. Teil

Dienstag, 28. Juli, 2009 – 10:53

So, nun ist seit gestern auch der zweite Teil unserer kleinen Artikelserie über EMF Compare erschienen. Den Artikel “Modellvergleich mit EMF Compare – Ein Praxisbeispiel” findet man im Eclipse Magazin 05.2009. Der Artikel ist ebenfalls in Zusammenarbeit mit meinen Kollegen Andreas Mülder und Holger Schill entstanden. Hier ein kurzer Abstract:

Als Ergebnis eines Vergleichs zweier Modelle erzeugt das Framework EMF Compare ein Übereinstimmungsmodell und ein Differenzmodell. Zur automatisierten Weiterverarbeitung sind diese Modelle gut geeignet, da sie selbst wiederum EMF Modelle sind. Im ersten Teil des Artikels wird beschrieben, wie man EMF Compare programmatisch verwendet um ein Differenzmodell zu erzeugen.

Zur Weiterverarbeitung von Modellen hat sich im Eclipse-Umfeld das Framework openArchitectureWare [1] etabliert. Mit diesem Framework ist es leicht möglich, Modell-zu-Text (M2T) bzw. Modell-zu-Modell (M2M) Transformationen durchzuführen. Im zweiten Teil des Artikels wird mittels einer Modell-zu-Text Transformation gezeigt, wie die Lesbarkeit des Ergebnisses von EMF Compare gesteigert werden kann, indem aus dem Differenzmodell ein HTML Report generiert wird.

Wieder viel Spaß beim Lesen!

Modellvergleich mit EMF Compare

Donnerstag, 28. Mai, 2009 – 12:05

Andreas Mülder, Holger Schill und ich haben im Eclipse Magazin 04.2009 einen Artikel zu EMF Compare veröffentlicht. Er ist der erste Teil einer Serie über EMF Compare. Der nächste Teil wird in der nächsten Ausgabe des Eclipse Magazins erscheinen. Hier ist ein kurzes Abstract des ersten Artikels:

Das Vergleichen und Zusammenführen EMF-basierter Modelle wurde bisher nur auf textueller Ebene im XML-Quelltext unterstützt. Bei der Entwicklung im Team führt das zu Problemen, da parallele Änderungen an Modellen so nur schwer zusammenzuführen sind. In diesem Artikel werden wir das EMF Compare-Framework vorstellen, das dagegen für den Vergleich die logische Struktur der Modelle heranzieht. Darauf aufbauend unterstützt ein Vergleichswerkzeug den Benutzer beim Zusammenführen unterschiedlicher Modelle.

Im Artikel ist auch eine kurze Studie über die Performanz von EMF Compare zu finden. Viel Spaß beim Lesen.

Von Affen und Spionen

Mittwoch, 21. Mai, 2008 – 11:18

“Monkey see, monkey do” – das ist ein grundlegendes Motto für Eclipse Plug-In Entwickler. Schaue dir den Original-Code von Eclipse an und mache es nach. Aber woher soll man wissen, aus welchem Plug-In eine bestimmte Funktion stammt und in welcher Klasse sie implementiert ist? Ich habe oft Stunden damit verbracht, zum Beispiel den entsprechenden Code für einen Dialog in den Unmengen von Plug-Ins und Klassen ausfindig zu machen. Dis Suche ist nun vorbei.

In Ganymed, der für Ende Juni angekündigten Ausgabe von Eclipse 3.4, wurde der “PDE Spy” eingeführt. Mit der Tastenkombination Alt-Shift-F1 wird ein Dialog geöffnet, der Informationen über die gerade aktive Selektion enthält. Dazu gehören die Klasse der aktiven Shell, die Klasse des Editors, das zugehörige Plug-In und viele andere Information. Und wie immer in Eclipse sind die Informationen mit Links versehen, um direkt in die Implementierungen springen zu können. Ein Feature, das ganz klar zu der Kategorie “Was ich schon immer vermisst habe” gehört.

PDE Spy

40 Jahre Software Engineering

Montag, 19. Mai, 2008 – 10:56

Schon gewußt? Der Begriff “Software Engineering” wurde vor 40 Jahren auf einem NATO Workshop in Garmisch, Deutschland geprägt. Auf der bedeutendsten internationalen Konferenz für Software Engineering ICSE vom 10. bis 18. Mai 2008 in Leipzig gab es ein Wiedertreffen einiger wichtiger Teilnehmer des Workshops. Es gab unter anderem eine Plenarrunde mit den beiden Herausgebern des damaligen Tagungsbandes, Prof. Peter Naur und Prof. Brian Randall, sowie mit Prof. Manfred Broy in Vertretung von Prof. Fritz Brauer. Fritz Brauer war der Organisator des NATO Workshops und prägte den Begriff “Software Engineering”.

Thema des NATO Workshops war die Softwarekrise, die Mitte der 60er Jahre begann. Software war damals eine “kostenlose” Beigabe zur Hardware. Sie konnte nicht einzeln erworben und mit beliebiger Hardware kombiniert werden. Wurde die Hardware gewechselt, mußte die Software jedesmal neu entwickelt werden. Die Programme wurden jedoch immer komplexer, systematische Vorgehensweisen zur Handhabung der Komplexität wie in den klassischen Ingenieurswissenschaften existierten aber nicht. Die ersten Softwareprojekte scheiterten. So wurde die Disziplin des Software Engineerings geboren.

Auf der International Conference on Software Engineering (ICSE) in Leipzig gab es aus diesem Grund auch eine Geburtstagstorte zum 40-sten Jahrestag des Software Engineering.