CSS-Styling im Eclipse

CSS und Eclipse 4.2
Kommentare

Bei Cascading Stylesheets (CSS) handelt es sich um eine deklarative Sprache, mit der vor allem im Web-Umfeld eine HTML-ergänzende Formatierung von Web Seiten durchgeführt werden kann. Das bedeutet konkret, dass man HTML-Dokumente mit sogenannten „Dokumentvorlagen“ (Stylesheets) verknüpft, welche die typografischen Informationen zum Erscheinungsbild der Seite enthalten. Damit kann im HTML-Dokument selbst der Fokus auf Struktur und Inhalt liegen, während das einheitliche Aussehen über CSS gesteuert wird. Durch diese Trennung können Änderungen am Erscheinungsbild schnell und problemlos, auch über mehrere HTML-Seiten hinweg, eingepflegt werden. Auf der anderen Seite werden die HTML-Seiten selbst schlanker und übersichtlicher, weil viel Code, der das Aussehen der Seite steuert, in den CSS-Bereich übergeht.

Auch wenn CSS heute als Standard-Stylesheetsprache für Webseiten gilt, so ist das Web nur ein Bereich in dem CSS eingesetzt werden kann. Laut Wikipedia ist es mit CSS möglich, Darstellungen für verschiedene Ausgabemedien wie Bildschirm, Papier, Projektion und Sprache vorzugeben. Dieses Kapitel erklärt zunächst grundsätzlich, wie CSS in Verbindung mit der Eclipse 4 Application Platform funktioniert, wie man es verwendet und schließlich wie man eigene Themes baut, zwischen denen man zur Laufzeit umschalten kann und somit das Aussehen einer Anwendung im laufenden Betrieb ändert.

Obwohl CSS auch im Eclipse 4.2 SDK zum Einsatz kommt, bringen die Standardpakete zunächst keinerlei Unterstützung und Werkzeuge zum Erstellen von Cascading Stylesheets mit. Die e4-Tools, die separat erhältlich sind, bieten allerdings umfangreiche Unterstützung für CSS. Neben einem Editor für CSS-Dateien, der Syntax-Highlighting und Codevervollständigung anbietet, sind insbesondere auch Werkzeuge zum Debuggen, Ausprobieren und zur Analyse von CSS-Bestandteilen in Eclipse-4-Anwendungen enthalten. Eine detaillierte Beschreibung zu den e4-Tools und den darin enthaltenen Werkzeugen für CSS findet sich in Kapitel 3.

CSS und Eclipse 4.2

Zunächst stellt sich natürlich die Frage: Wenn sich mit Hilfe von CSS eine saubere und einheitliche Trennung zwischen dem fachlichen Teil und der Darstellung erreichen lässt, warum hat diese Technik noch nicht längst Einzug in die Anwendungsentwicklung gehalten? In Eclipse 3.x erfolgte die Steuerung des Aussehens einer Anwendung über das Presentation API, beziehungsweise über verschiedene Properties in den verwendeten Widgets. Abgesehen von der Tatsache, dass es statt einem einheitlichen hier eigentlich zwei verschiedene Wege zum Ziel gab, führt diese Vorgehensweise definitiv zur Vermischung von Layout-spezifischem und fachlichem Code. Dieses Problem erkannte man auch in der Eclipse Community recht früh und bald keimte die Idee, in Zukunft auf CSS zu setzen. CSS zur Gestaltung der Oberfläche entstand schließlich im Rahmen der Entwicklung der e4-Technologie, jedoch als eigenständige und unabhängige Komponente. Dies bedeutet, dass mit Eclipse 4 CSS zwar Einzug hält, die Komponente selbst sich jedoch auch herauslösen und genauso in Eclipse-3.x-Anwendungen verwenden lässt.

Gestaltet man eine e4-Anwendung mit CSS, legt man die eigentlichen Gestaltungsregeln typischerweise in einer separaten Stylesheet-Datei ab. Die Syntax orientiert sich am CSS-Standard. In einem Stylesheet werden Regeln für die verschiedenen Teile der Anwendung definiert, diese werden auch CSS-Regeln oder CSS-Rules genannt. Eine solche Regel wird per Definition mit einem sogenannten „Selektor“ eingeleitet, der auf das zu gestaltende Objekt oder eine Objektgruppe verweist. Darauf folgen die eigentlichen Gestaltungsmerkmale. Diese stehen zwischen geschweiften Klammern in einem Block und sind in der Form Attribut und Attributwert anzugeben, jeweils getrennt durch Doppelpunkt. Das folgende Listing zeigt am Beispiel eines Labels, wie ein solcher CSS-Block aussehen kann:

Label {
   font: Arial 10px;
   color: rgb(255,255,255);
}

Der Block wird durch den Selektor „Label“ eingeleitet, was in diesem Fall bedeutet, dass die CSS-Regel für alle SWT-Elemente vom Typ „Label” gilt. Sie bezieht sich somit auf eine Objektgruppe. Innerhalb des Blocks sind die eigentlichen Gestaltungsmerkmale (Schriftart Arial in bestimmter Größe in weißer Farbe) definiert. Mit Selektoren hat man zusätzlich die Möglichkeit, verschiedene Bedingungen zu definieren, die auf ein Element zutreffen müssen, damit der nachfolgende Satz an CSS-Gestaltungsmerkmalen auf die jeweiligen Elemente angewendet werden. Die verschiedenen Arten von CSS-Selektoren werden in Abschnitt 7.2 näher beschrieben.

Abbildung 7.1: CSS kann bei der Gestaltung hierarchisch vorgehen

Die CSS-Komponente geht beim Anwenden eines Stylesheets auf die einzelnen SWT-Elemente hierarchisch vor. Wie in Abbildung 7.1 zu sehen ist, lässt sich CSS auf SWT genauso abbilden wie auf HTML. Wird als Selektor beispielsweise „Shell“ ausgewählt, bezieht sich die nachfolgende CSS-Regel auf alle Shells in der Anwendung, nicht jedoch auf die in der Hierarchie folgenden Elemente (Composite, Combo und so weiter). Ein solches Miteinbeziehen darunterliegender Elemente erreicht man durch den Einsatz von Descendant Selectors oder Child Selectors. Hierbei handelt es sich um eine Sonderform von Selektoren, welche in Abschnitt 7.2.4 mit Beispielen beschrieben werden.

Das Aussehen der Eclipse 4 IDE mit CSS verändern

Bevor das Erzeugen und die Integration von individuellen CSS-Dateien in eigene Anwendungen beschrieben wird, soll zunächst gezeigt werden, wie man mit wenigen Handgriffen die CSS-Regeln einer laufenden Eclipse-IDE einsehen und verändern kann. Hierzu muss die Eclipse-IDE nicht verlassen werden. Über die Preference-Seite General | Appearance lässt sich nicht nur zwischen den einzelnen Themes umschalten, es werden auch die CSS-Regeln des gerade ausgewählten Themes angezeigt (Abbildung 7.2) wenn die e4-Tools installiert sind.

Abbildung 7.2: Sind die e4-Tools installiert, kann der CSS-Code des ausgewählten Themes sogar editiert werden

Diese werden in einem Editor mit Syntax-Highlighting dargestellt und können direkt verändert werden. Mit einem Klick auf den „Apply“-Knopf werden alle Änderungen gespeichert und sind sofort aktiv. Ändert man hier beispielsweise den Bereich, der mit dem Selector „.MPartStack“ eingeleitet wird wie folgt, erhalten alle Reiter in der Workbench das klassische SWT-Design zurück, inklusive der schräg abgerundeten Reiter.

.MPartStack {
   swt-tab-renderer: null;
   font-size: 15;
   swt-simple: false;
}

In Kapitel 4 wurden PartStacks als eines der zentralen Layout-Elemente für Perspektiven vorgestellt, in der Eclipse Workbench kommen PartStacks überall dort zum Einsatz, wo Reiter dargestellt werden. Der CSS-Selector „.MPartStack“ wählt alle Elemente vom Typ MPartStack aus. Der einleitende Punkt legt dabei fest, dass dieser Selektor auf alle Elemente vom angegebenen Typen (hier MPartStack) im Application Model wirken soll. Zum modernen Design der neuen Eclipse 4-Workbench tragen auch die neugestalteten, in einem weißlichen Ton gehaltenen, Reiter bei. Dieses neue Aussehen wird durch einen eigenen, speziellen Renderer für das CTabFolder-Widget erreicht. Die erste Zeile in dem ausgewählten CSS-Theme importiert dazu zunächst ein Basis-Stylesheet. Um dieses Basis-Stylesheet (e4_basestyle.css) im Preference-Editor zu betrachten, muss man lediglich das Theme „Default Theme“ auswählen. Dort gibt es ebenfalls einen „.MPartStack“-Selektor, hier findet sich die Verknüpfung mit dem Eclipse 4-spezifischen CTab-Renderer:

.MPartStack {
   swt-tab-renderer: 
         url('bundleclass://org.eclipse.e4.ui.workbench.renderers.swt/
               org.eclipse.e4.ui.workbench.renderers.swt.CTabRendering');
   ...
}

Im Listing weiter oben wird diese Default-Angabe mit dem Wert null überschrieben, somit kommt also wieder der Standard-Renderer zum Einsatz. Das Attribut swt-simple greift erst, wenn der Standard-Renderer wieder aktiv ist und sorgt dafür, dass die Reiter eckig dargestellt werden. Stellt man dieses Attribut auf false, erhält man die aus früheren Eclipse-Versionen bekannten abgerundeten Reiter. Änderungen an den CSS-Regeln, die über die Preference-Seite, wie hier beschrieben, vorgenommen wurden, lassen sich mit Hilfe des Knopfs „Restore Defaults“ jederzeit wieder zurücknehmen. Abbildung 7.3 zeigt, wie sich die Eclipse-IDE mit Hilfe von CSS verändern lässt. Im oberen Ausschnitt kommt das mitgelieferte Standard-CSS mit dem bereits erwähnten Tab-Renderer zum Einsatz. Der untere Ausschnitt zeigt, wie sich die DIE verändert wenn man die weiter oben beschriebenen Veränderungen im Standard-CSS vornimmt.

Abbildung 7.3: Das Aussehen der Eclipse-IDE mit CSS verändern

CSS in Eclipse-4-Anwendungen verwenden

Interessant ist jetzt natürlich die Frage, wie sich CSS-Styling in der eigenen Anwendung verwenden lässt. CSS lässt sich entweder fest, dynamisch oder programmatisch einbinden. Bei der festen Konfiguration wird die Anwendung mit einer CSS-Datei ausgestattet, die alle anzuwendenden Gestaltungsmerkmale enthält. Ein spezieller Parameter in der Datei plugin.xml legt in diesem Zusammenhang fest, welche CSS-Datei verwendet werden soll. Bei dynamischer Konfiguration können beliebig viele CSS-Dateien als sogenannte Themes eingebunden werden. Ein eigenes API (Theme Engine API) ermöglicht es dem Entwickler dann zur Laufzeit zwischen den einzelnen Themes umzuschalten. Unabhängig davon, ob CSS in fester oder dynamischer Weise aktiviert wird, müssen mindestens folgende Plugins in die Anwendung eingebunden sein:

  • org.eclipse.e4.ui.css.core
  • org.eclipse.e4.ui.css.swt

Selbstverständlich besitzen auch die soeben aufgeführten Bundles wiederum Abhängigkeiten zu anderen Bundles, diese lassen sich jedoch über die Product-Datei oder aus der Run Configuration des Projekts über den Knopf „Add Required“ auflösen. Erstellt man eine e4-Anwendung mit Hilfe des „Eclipse 4 Application Project“-Wizards (eine Beschreibung hierzu findet sich in Kapitel 3), dann wird das Projekt bereits für CSS-Styling vorbereitet. Dabei kommt die Variante der festen Konfiguration zur Anwendung.

[header = Feste Konfiguration mit einer CSS-Datei]

Feste Konfiguration mit einer CSS-Datei

Wie bereits erwähnt, ist eine CSS-Datei mit den Gestaltungsmerkmalen als Grundlage für die CSS-Engine erforderlich. Diese muss der CSS-Engine bekannt gemacht werden. Hierzu bedient man sich im Rahmen der festen Konfiguration des Extension Points „org.eclipse.core.runtime.products“, eines Erweiterungspunkts, der ohnehin in nahezu jeder e4-Anwendung verwendet wird. Über diesen Extension Point wird eine e4-Anwendung als Produkt registriert. Weiterhin wird an diesem Extension Point mit Hilfe des Parameters „applicationXMI“ das initiale Application Model registriert. Auf ganz ähnliche Weise, durch den Parameter „applicationCSS”, erfolgt hier auch die Aktivierung der CSS-Datei:

<extension id="product" point="org.eclipse.core.runtime.products">
   <product name="PartStacks"
            application="org.eclipse.e4.ui.workbench.swt.E4Application">

      <property name="appName" 
               value="PartStacks">
      </property>
      <property name="applicationXMI"
                value="PartStacks/Application.e4xmi">
      </property>
      <property name="applicationCSS"
                value="platform:/plugin/PartStacks/css/my_theme.css">
      </property>

   </product>
</extension>

Der oben dargestellte Ausschnitt aus der plugin.xml zeigt, wie über den Parameter „applicationCSS” die Verknüpfung mit der CSS-Datei erfolgt und damit implizit die Aktivierung der CSS-Engine. Sobald diese Einstellung erfolgt ist und die entsprechende Datei vorliegt, wird beim nächsten Start der Anwendung dass CSS-Styling aktiv. Da es sich bei der CSS-Datei aus Eclipse-Sicht um eine Ressource handelt, ist die Datei-URI hier in der Platform-Notation anzugeben.

Das folgende Listing enthält die CSS-Regeln für die Datei „my_theme.css“. Alle Attribute die mit „swt“ beginnen, bezeichnen direkt Eigenschaften der darunterliegenden SWT-Komponenten. So verweist das Attribut „swt-tab-renderer“ auf den Setter „setRenderer“ des CTabFolder-Widgets und bewirkt, dass der angegebene Renderer an den Setter übergeben wird. Da es sich bei dem Renderer um eine Klasse handelt, muss die Angabe hier in der Bundleclass-Notation erfolgen. Auf den Unterschied zwischen Platform- und Bundleclass-Notation wurde in Kapitel 4 näher eingegangen.

.MPartStack {
   swt-tab-renderer: 
         url('bundleclass://org.eclipse.e4.ui.workbench.renderers.swt/
               org.eclipse.e4.ui.workbench.renderers.swt.CTabRendering');
   swt-font-size: 12;
   swt-unselected-tabs-color: #F3F9FF #D0DFEE #CEDDED #CEDDED #D2E1F0 
     #D2E1F0 #FFFFFF 20% 45% 60% 70% 100% 100%;
   swt-outer-keyline-color: #B6BCCC;
   swt-inner-keyline-color: #FFFFFF;
}

#MyTag {
  background-color: rgb(0,0,0);
  color: white;

Die Theme Engine API verwenden

Soll eine Eclipse-4-Anwendung mit einem festen Standard-Theme auskommen, reicht es, wenn man wie im vorangegangenen Abschnitt beschrieben vorgeht. Es gibt allerdings auch die Möglichkeit, mehrere Themes mit einer Anwendung auszuliefern und dem Anwender die Möglichkeit zu geben, zwischen diesen zu wechseln ohne die Anwendung neu starten zu müssen. Die Eclipse-IDE selbst ist ein gutes Beispiel für eine Anwendung, die mehrere Themes mitbringt. So gibt es zunächst für jedes Betriebssystem ein eigenes Look and Feel, außerdem kann man im Preference-Dialog, wie weiter oben bereits beschrieben, zwischen verschiedenen Themes umschalten. Technisch gesehen liegt jedes Theme als CSS-Datei vor und muss in einem Ressourcen-Ordner innerhalb der Anwendung vorliegen. Damit die Platform die verschiedenen Themes erkennt, müssen diese registriert werden. Hierzu stellt Eclipse 4 den speziellen Extension Point „org.eclipse.e4.ui.swt.theme“ zur Verfügung. An diesem Extension Point ist jedes Theme anzumelden, das in der Anwendung aktiviert werden können soll. Die Theme Engine API ermöglicht später das Umschalten zwischen den einzelnen Themes. Damit dieser Extension Point sowie die zugehörige Theme Engine API zur Verfügung steht, ist zusätzlich das folgende Bundle (als required Plug-In) in die Datei MANIFEST.MF des Projekts aufzuznehmen:

  •  org.eclipse.e4.ui.css.swt.theme

Im Folgenden soll die Vorgehensweise zum Einbinden von Themes anhand von zwei sehr einfachen Themes durchgespielt werden. Die Anwendung soll dabei in die Lage versetzt werden zwischen einer normalen Ansicht (Standard Theme) und einer Ansicht mit besonders großen Schriften (Big Fonts Theme) umschalten zu können. Die beiden Themes sind in zwei CSS-Dateien hinterlegt:

  • standard.css (Standard Theme)
  • bigfonts.css (Big Fonts Theme)

Wie bereits erwähnt, müssen die beiden Themes zunächst am weiter vorne erwähnten Extension Point registriert werden. Themes sind nicht Bestandteil des Application Models. Die Registrierung erfolgt von daher auf dem Standardweg über die Datei plugin.xml:

<extension
   point="org.eclipse.e4.ui.css.swt.theme">
   <theme
      basestylesheeturi="css/standard.css"
      id="net.teufel.themes.standard"
      label="Standard Theme ">
   </theme>
   <theme
      basestylesheeturi="css/bigfonts.css"
      id="net.teufel.themes.bigfonts"
      label="Big Font Theme">
   </theme>
 </extension>

Bei der Registrierung wird eine ID angegeben, über die das Theme eindeutig identifizierbar ist. Danach folgt ein Label, das man beispielsweise in der Anwendung zur Auswahl des aktuell gültigen Themes anzeigen kann. Der Parameter „basestylesheeturi“ gibt den Pfad zur CSS-Datei an, die das Theme beinhaltet. Alle drei Angaben sind verpflichtend. Alle weiteren Angaben dagegen optional. Die optionalen Angaben, die man beim Anmelden eines Themes beim Theme Manager noch machen kann, beschreiben zum Beispiel, für welches Betriebssystem das Theme geeignet ist, und genauer für welche Betriebssystem-Version (Parameter „os“ und „os_version“). Lässt man diese Angaben leer, geht die Eclipse 4 Application Platform davon aus, dass das betreffende Theme auf jedem Betriebssystem eingesetzt werden kann. Schließlich kann man noch angeben, wenn sich ein Theme nur auf ein bestimmtes Windowing-Toolkit, etwa GTK unter Linux, bezieht (Parameter „ws“).

Im vorangegangenen Abschnitt wurde schon beschrieben, wie man mit Hilfe der Property „applicationCSS“ im Extension Point „org.eclipse.core.runtime.products“ ein festes CSS-Theme für eine Anwendung vorgeben kann. Diese Property wird bei Verwendung der Theme Engine API nicht mehr beachtet. An seine Stelle tritt nun der Parameter „cssTheme“ um zunächst einmal festzulegen, welches der registrierten Themes das Standard-Theme darstellt. Theoretisch kann man diesen Parameter auch als Alternative zu „applicationCSS“ verwenden. In diesem Fall muss das Theme, auch wenn nur dieses eine ausgeliefert wird, trotzdem beim Extension Point „org.eclipse.e4.ui.swt.theme“ angemeldet werden. Damit das Standard-Theme über die Property „cssTheme“ angezogen wird, ist die Produktkonfiguration in der plugin.xml wie nun folgt zu ändern:

<extension
   id="product"
   point="org.eclipse.core.runtime.products">
   <product
      name="PartStacks"
      application="org.eclipse.e4.ui.workbench.swt.E4Application">
      <property
         name="appName"
         value="PartStacks">
      </property>
      <property
         name="applicationXMI"
         value="PartStacks/Application.e4xmi">
      </property>
      <property
         name="cssTheme"
         value="net.teufel.themes.standard">
      </property>
   </product>
</extension>

Zu beachten bei diesen beiden Listings ist, dass die Angabe des Datei-Pfads zum Theme im relativen Format erfolgt. Die Angabe des Standard-Themes beim Produkt selbst (letztes Listing über Parameter „cssTheme“) erfolgt jedoch über dessen Theme-ID!

Damit sind alle Basis-Einstellungen erledigt: Die in der Anwendung zur Verfügung stehenden Themes sind registiert und das Standard-Theme ist festgelegt. Jetzt fehlt noch die Möglichkeit, zur Laufzeit zwischen diesen beiden Themes umzuschalten. Für den Umgang mit Themes bietet die Eclipse 4 Application Platform dazu den Service „IThemeEngine“ an, den man sich mit Hilfe von Dependency Injection übergeben lassen kann. Eine der zentralen Methoden, die dieser Service anbietet, ist setTheme(). Ruft man diese Methode auf und übergibt die ID eines Themes, führt dies dazu, dass dieses Theme aktiv wird und alle Gestaltungsregeln aus der dahinterliegenden CSS-Datei sofort auf alle Komponenten der laufenden Anwendung wirken. Das folgende Listing zeigt, wie man beispielsweise aus einem Handler heraus auf das „Big Fonts“-Theme umschalten kann:

public class SwitchThemeHandler {
   @Execute
   public void switchToBigFonts(IThemeEngine themeEngine) {
      themeEngine.setTheme("net.teufel.themes.bigfonts ",true);
   }
}

In diesem Beispiel wird der ThemeEngine-Service implizit über Dependency Injection in den Handler übergeben. Durch Aufruf der Methode setTheme() und unter Angabe der ID des Themes, auf den umgeschaltet werden soll, wird der eigentliche Wechsel ausgelöst. Der zweite Parameter, der an die Methode setTheme() übergeben wird, bestimmt, ob diese Einstellung gespeichert werden soll. Der Wert true legt also fest, dass dieses Theme als neues Standard-Theme gespeichert und bei einem Neustart der Anwendung wiederverwendet wird.

Der ThemeEngine-Service bietet noch weitere interessante Methoden an. Eine Zusammenfassung findet sich in Tabelle 7.1.

Methode

Beschreibung

setTheme(themeid, true/false)

Legt das aktuelle Theme fest. Es muss hier eine vorher beim Extension Point „org.eclipse.e4.ui.css.swt.theme“ angemeldete Theme-ID angegeben werden. Der zweite Parameter steuert, ob diese Einstellung gespeichert werden soll, so dass beim Neustart das zuletzt eingestellte Theme wiederhergestellt werden kann.

registerTheme(themeid, label, basestylesheeturi, osVersion)

Alternativ zum Registrieren von Themes über den Extension Point besteht mit dieser Methode die Möglichkeit, Themes optional auf programmatische Weise beim System anzumelden.

getActiveTheme()

Liefert das aktuell eingestellte Theme zurück. Es wird ein Objekt vom Typ ITheme zurückgeliefert, welches alle Informationen zum Theme (ID, Label, URI, usw) kapselt.

getThemes()

Liefert eine Liste aller registrierten Themes vom Typ List<ITheme>. Damit können beispielsweise Menüs zum Umschalten zwischen den verfügbaren Themes erzeugt werden.

Tabelle 7.1: Hilfreiche Methoden des ThemeEngine-Services im Überblick

Es ist auch möglich, sich informieren zu lassen, wenn ein Theme-Wechsel über die Theme Engine API stattgefunden hat. Hierzu sendet die Theme Engine ein Event an den Event Broker. Das zugehörige Topic ist in folgendem Interface notiert:

IThemeEngine.Events.THEME_CHANGED

Mit Hilfe der @EventTopic-Annotation kann man sich also beim Event Broker anmelden und bekommt dann, vorausgesetzt man hat sich mit dem oben angegebenen Topic registriert, alle wichtigen Information zum Theme-Wechsel in einem Event-Objekt geliefert. Es kann abgefragt werden, auf welches Theme gewechselt wurde, das betreffende Display wird geliefert und schließlich wird mitgeteilt, auf welchem Wert das Restore-Flag beim Aufruf von setTheme() gesetzt wurde. Das folgende Beispiel registriert sich beim Event Broker und schreibt alle Informationen auf die Konsole, sobald das Theme gewechselt wird:

@Inject @Optional
public void 
 handleEvent(@EventTopic(IThemeEngine.Events.THEME_CHANGED) Event event){
   System.out.println("Topic: " + event.getTopic());
   System.out.println("Theme: " +                      
     event.getProperty(IThemeEngine.Events.THEME));
   System.out.println("Device: " +
     event.getProperty(IThemeEngine.Events.DEVICE));
   System.out.println("Restore: " +
     event.getProperty(IThemeEngine.Events.RESTORE));
}

Beim Wechsel des Themes sollte das oben abgebildete Listing zu folgender Ausgabe führen:

Topic: org/eclipse/e4/ui/css/swt/theme/ThemeManager/themeChanged
Theme: Theme [id=net.teufel.themes.bigfonts, label='Big Font Theme', osVersion=null]
Device: org.eclipse.swt.widgets.Display@30114
Restore: true

Tiefer gehende Informationen zum Event Broker und dem in der Eclipse 4 Application Platform enthaltenden Event System finden sich in Kapitel 6.

CSS programmatisch einbringen

Beim Einlesen von CSS-Dateien zur Gestaltung von SWT-Oberflächen verwendet Eclipse intern die Klasse org.eclipse.e4.ui.css.swt.CSSSWTEngineImpl.

Diese Klasse implementiert das generische Interface org.eclipse.e4.ui.css.core.engine.CSSEngine. Auch wenn mit dem Eclipse 4.2 SDK zur Zeit nur die oben erwähnte Implementierung für SWT ausgeliefert wird, so sind CSSEngine-Implementierungen auch für andere UI-Toolkits wie etwa Swing oder JavaFX denkbar. Manchmal kann es sinnvoll sein, CSS-Regeln manuell ins Programm einzustreuen, also programmatisch hinzuzufügen beziehungsweise bestehende Regeln neu zu definieren oder zu verändern. Zu diesem Zweck kann man die CSSSWTEngine auch manuell bedienen. Das folgende Listing zeigt, wie mit ein paar Zeilen Programmcode die CSS-Regel für Label verändert werden kann:

CSSEngine engine = new CSSSWTEngineImpl(parent.getDisplay());
engine.parseStyleSheet(new StringReader(
   "Label { background-color: orange }"));
engine.setErrorHandler(new CSSErrorHandler() {
  public void error(Exception e) {
    e.printStackTrace();
  }
});
engine.applyStyles(parent.getShell(),true);

Im Beispiel wird die CSSSWTEngineImpl manuell instanziiert. Auf der Eclipse 4 Application Platform kann man sich diese selbstverständlich via Dependency Injection bereitstellen lassen. Mit Hilfe der Methode parseStyleSheet() wird der anzuwendende CSS-Code übergeben, hier unter Zuhilfenahme eines StringReaders. Optional kann man einen Error Handler an die CSSEngine binden, welcher benachrichtigt wird, wenn beispielsweise beim Parsen des CSS-Codes ein Fehler aufgetreten ist. Mit der Methode applyStyles() werden die Änderungen schließlich aktiv. Der erste Parameter bestimmt, ab wo in der Hierarchie der SWT-Komponenten die entsprechende CSS-Regel angewendet werden soll. Im Beispiel wird die Shell angegeben, was zur Folge hat, dass die neue CSS-Regel auf alle Elemente (vom Typ Label) der Shell angewendet wird. Der zweite Parameter legt fest, ob die neuen Regeln auch auf alle Kind-Elemente wirken sollen. Wenn ja (true), läuft die CSSEngine hierarchisch durch alle Kind-Elemente und setzt die Gestaltungsregeln bis auf die unterste Ebene der Hierarchie durch.

Theoretisch ist es möglich auch ganz auf CSS-Dateien zu verzichten und die CSS-Regeln komplett auf Basis der Klasse CSSSWTEngineImpl zu setzen. Hiervon wird aber dringend abgeraten, denn durch diese Vorgehensweise vermischen sich CSS-Regeln mit Programmcode. Dadurch wird die Wartung der Anwendung nicht nur erschwert, ein ganz wesentlicher Vorteil von CSS, nämlich die Trennung von Gestaltungsregeln und Programmcode geht dabei verloren.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -