Das Aussehen der grafischen Oberfläche entscheidet über den ersten Eindruck beim Benutzer. Sie sorgt außerdem für den Wiedererkennungswert der Anwendung, was vor allem bei kommerzieller Software im Interesse jedes Entwicklers liegt. Mit der Rich Client Platform geschaffene Anwendungen gleichen sich jedoch zunächst wie ein Ei dem anderen. Das Schaffen eines individuellen Oberflächendesigns heißt im Eclipse-Jargon Branding und sorgt dafür, dass kreative und praktische Ideen des Entwicklers ins Programm einfließen.
Branding leicht gemacht
Der erste Teil dieses Artikels widmet sich den für das Branding notwendigen Schritten. Der zweite Teil kümmert sich um eine Introseite und die Hilfefunktion. Die Introseite erläutert neuen Benutzern Sinn und Zweck der Anwendung. Eine Hilfe ist gerade bei komplexen Programmen wichtig, ihre Bedeutung unterschätzen die meisten Programmierer allerdings. Zumindest bei dem technischen Aufwand für solche Aufgaben nimmt die Rich Client Platform dem Entwickler viel Arbeit ab.
Die ersten Folgen des RCP-Tutorials zeigten die Entwicklung einer Applikation. Der in der einfachen Variante nötige Start des Programms über ein Shellskript ist für Linux-Benutzer nicht ungewöhnlich. Auf anderen Plattformen ist dies Vorgehen jedoch schon deshalb problematisch, weil sich die Möglichkeiten der plattformspezifischen Skriptsprachen im Einzelnen deutlich unterscheiden.
Das Branding setzt zusätzlich zu der Application ein so genanntes Product voraus. Es definiert die Konfigurationseinstellungen, darunter einen Verweis auf jene Application, die das Skript ausführen soll. Damit ist ein Product die Hülle um eine bestehende Anwendung.
Um es anzuwenden, benötigt man zuerst eine »MANIFEST.MF«-Datei. Auf der ersten Seite des Plugin-Editors (der Reiter heißt »Overview«) steht unter »Plug-in Content« der Link »create an OSGI bundle manifest«. Er erzeugt diese Datei automatisch.
Zum Erstellen eines Products in Eclipse wählt man einen geeigneten Extension Point - in diesem Beispiel »org.eclipse.core.runtime.products« - und implementiert ihn. Der dafür zuständige Wizard unter »File | New | Other... | Product Configuration« erledigt die meiste Handarbeit automatisch (Abbildung 1).
Von der Anwendung zum Produkt
Zur Bearbeitung der so erzeugten Datei »epm.product« dient der eingebaute Product-Editor, der beim Doppelklick auf das File startet. Im Reiter »Overview« (Abbildung 2) wählt der Eclipse-Programmierer die Produkt-ID, die Applikation und den Namen des Produkts. Der Link »Synchronize« rechts unten erweitert danach die Datei »plugin.xml« um die entsprechenden Zeilen (siehe Listing 1). An dieser Stelle verhält sich Eclipse nicht ganz konsistent: Über den Product-Editor vorgenommene Einstellungen landen in der Datei »plugin.xml«, umgekehrt übernimmt der Product-Editor Änderungen in der »plugin.xml« jedoch nicht automatisch.
Der Reiter »Configuration« enthält Angaben zu den Plugins, den Startparametern und der zu erzeugenden Konfigurationsdatei (Abbildung 3). In der linken Box stehen die Plugins und Fragmente des Produkts. Fragmente sind Teile von Plugins, die der Update-Mechanismus von Eclipse nachladen kann. Hier ist zwar jedes notwendige Plugin manuell einzutragen, der Plugin-Editor enthält aber im Reiter »Dependencies« eine Liste aller Plugins; aus dieser Listenansicht lassen sie sich bequem übertragen.
Nun steht dem Start des Produkts direkt über die »Overview«-Seite nichts mehr im Weg. Anschließend exportiert es der Entwickler über den »Eclipse Product Export Wizard«. Jetzt ist der Programmstart bereits per »Eclipse Executable« möglich, das Shellskript aus dem ersten Teil des Tutorials hat ausgedient.
Vor dem Start der Anwendung empfiehlt es sich, im Unterverzeichnis »configuration« des Exportverzeichnisses alle Unterverzeichnisse, die mit »org.eclipse« beginnen, zu löschen. Das ist ebenfalls Pflicht für alle, die an der Anwendung selbst Änderungen vornehmen. Auch beim Export-Wizard treten gelegentlich Schwierigkeiten auf. Hier hilft es, das Projekt zu schließen und erneut zu öffnen und zu exportieren.