Visuelle Werkzeuge erfreuen sich in der Softwareentwicklung seit jeher großer Beliebtheit. An erster Stelle müssen hier GUI-Builder (GUI = Graphical User Interface) genannt werden, mit denen sich grafische Programmoberflächen erheblich leichter als in einem Texteditor gestalten lassen. Während klassische integrierte Entwicklungsumgebungen in der Regel über einen fest eingebauten GUI-Builder verfügen, enthält die Standarddistribution von Eclipse bislang kein derartiges Werkzeug.
Dieses Manko lässt sich aber leicht ausgleichen, denn Eclipse ist über seine Plugin-Schnittstelle erweiterbar. Das bedeutet, dass auch die Java-Entwicklungsumgebung von Eclipse mit einem beliebigen GUI-Builder-Plugin ausgestattet werden kann. Die drei bekanntesten Produkte sind die kommerziellen Tools "Jigloo" und "Window Builder Pro" (bestehend aus "SWT Designer" und "Swing Designer") sowie der frei erhältliche "Visual Editor".
Jigloo
Der GUI-Builder mit dem originellen Namen Jigloo stammt von der US-amerikanischen Firma Cloudgarden. Wie alle derartigen Eclipse-Module ist das Plugin, das hier in der Version 3.0.1 getestet wurde, entweder über die Softwareaktualisierung der Hersteller-Homepage oder konventionell zu installieren. Letzteres geschieht, in dem man die Plugin-Bestandteile in den Plugin-Ordner und die neuen Feature-Bestandteile in den Feature-Ordner von Eclipse zieht und die Workbench neu startet.
Jigloo bereichert die Eclipse-Workbench um einen Form Editor, eine veränderte Outline-View und eine neue Properties-View. Über die Properties lassen sich das Erscheinungsbild, das Einlesen des Codes (Reverse Engineering) und die Codegenerierung steuern. Zudem können durch den Properties-Dialog so genannte Custom Controls angegeben und das Plugin für kommerzielle Zwecke freigeschaltet werden.
Die Einstellungen für das Erscheinungsbild erlauben die gleichzeitige Darstellung von Entwurfsmodus und Quelltext, wobei beide Fenster über einen Splitter getrennt werden. Jigloo lässt sich aber auch so einrichten, dass beide Ansichten getrennt über einen Reiter umgeschaltet werden. Die Verzögerung beim Einlesen des Quelltextes kann man in Millisekunden vorwählen. Dadurch verzögert sich die Synchronisation zwischen Code und Entwurfsansicht, was bei der Arbeit manchmal sehr hilfreich ist. Weiterhin können zwei verschiedene Arten von geschützten Blöcken definiert werden. Sie sorgen dafür, dass Codeteile bei der Generierung von neuem Quelltext unberührt bleiben oder sogar beim Reverse Engineering nicht mehr eingelesen werden.
Die Einflussmöglichkeiten auf die Codegenerierung beschränken sich auf wenige Einstellungen. Hier lässt sich zum Beispiel angeben, ob voll qualifizierte Bezeichner verwendet werden sollen. Für das schnelle Oberflächenprototyping ist praktisch, dass das Plugin Vorlagen für manche Widget-Modelle anlegen kann. Wenn man beispielweise eine neue Swing-Tabelle anlegt, erzeugt Jigloo gleich einen Rumpf des dazu passenden Modells.
Weiterhin lässt sich festlegen, ob neue Komponenten im Stil anderer GUI-Builder wie dem Visual Editor angelegt und Layouts in XML-Dateien ausgelagert werden sollen. Damit erschöpfen sich aber auch schon die Einstellungsmöglichkeiten. Was fehlt, ist zum Beispiel wenigstens eine Option, den Namen der Initialisierungsmethode festzulegen oder zu verhindern, dass auch bei Dialogen eine Main-Methode sowie überflüssiger Code und Kommentare erzeugt werden.
Jigloo kommt sowohl mit AWT-, Swing- als auch mit den neuen SWT-Klassenbibliotheken des Eclipse-Projekts zurecht. Einzigartig ist das Feature, zwischen einem Swing- und einem SWT-GUI hin- und herschalten zu können. Diese Funktion erzeugt jeweils vollständig neuen Quelltext, der in diesem Test jedoch nicht zuverlässig ohne Nacharbeiten funktionierte. Jigloo verfügt über gut strukturierte Paletten mit allen wichtigsten Javabeans der genannten Java-Bibliotheken. Neue Beans lassen sich problemlos hinzufügen. Insgesamt ist die Oberfläche nicht überladen und sehr leicht zu bedienen. Selbst komplexe Gridbag-Layouts bleiben übersichtlich.
Die Entwurfsansicht (Form Editor) ist sehr leistungsfähig und gestattet die Anordnung von Widgets nach allen erdenklichen Möglichkeiten. Er zeigt aber auch einige Schwächen. Bei manchen Layouts platziert das Plugin Widgets nicht korrekt. Löscht man Widgets, erfolgt manchmal kein Refresh der Oberflächen. Das führt dazu, dass hin und wieder die Konturen der Oberflächenbausteine auf dem Bildschirm stehen bleiben. Erst ein erneutes Laden der Klasse zeigt dann die korrekte Entwurfsansicht. Auch lässt sich bei der Gestaltung von Swing-Oberflächen nicht zwischen dem Look and Feel wechseln, ohne dass entsprechender - in diesem Fall redundanter - Code für das Setzen eines Look and Feel erzeugt wird.
All die genannten Schwächen sind jedoch Bagatellen im Vergleich zur fehlerhaften Synchronisierung zwischen Quelltext und Entwurfsansicht. Sie ist der größte Schwachpunkt des Produkts. Aus diesem Grund sollte man die Synchronisation bei Umstrukturierungen ausschalten oder die Klasse nur in den Texteditor laden. Vergisst man dies und strukturiert das Layout häufiger um, kommt es schnell zu Inkonsistenzen. Das äußert sich zum Beispiel beim Löschen von Widgets in Form von überflüssigen Importanweisungen, die als toter Code erhalten bleiben.
Die Probleme können bei weitgehenden Restrukturierungen dazu führen, dass die Entwurfsansicht einfriert. Zwar verfügt das Plugin für diese Fälle über einen Befehl, den Quellcode erneut zu parsen (KONTEXTMENÜ > RELOAD FORM EDITOR). Doch beim Einfrieren des Form Editor bleibt dieser Menübefehl sinnigerweise verborgen. Der Entwickler hat dann keine andere Wahl, als das Projekt zu schließen und wieder zu öffnen. Alles in allem ist Jigloo ein sehr interessantes Produkt, bei dem einige unübersehbare Schwächen die ansonsten sehr gute Funktionalität beinträchtigen.
Visual Editor
Das Visual-Editor-Projekt (VEP) ist mehr als ein GUI-Builder-Plugin zur Entwicklung grafischer Oberflächen. Hintergrund ist es, eine Basis zur Entwicklung von Eclipse-GUI-Buildern zu schaffen. Bei diesem Projekt standen mehrere Firmen Pate: Der ursprüngliche Code stammt von Advanced Systems Concepts, Canoo, IBM, Instantiations (siehe Window Builder Pro) sowie Red Hat.
Das VEP-Projektteam hat den von den Firmen gespendeten Code mittlerweile in Frameworks konsolidiert und den GUI-Builder Visual Editor in der Version 1.0 geschaffen. Das auf der Eclipse-Homepage erhältliche Tool ist erfreulicherweise jetzt zu Eclipse 3.0.1 kompatibel und als Referenzimplementierung der Frameworks gedacht. Doch wie viele Java-Referenzimplementierungen lässt er sich auch - mit gewissen Einschränkungen - für die tägliche Arbeit einsetzen.
Zur Installation des Plugins lädt man das Produkt entweder konventionell von der Eclipse-Seite herunter und kopiert es in die entsprechenden Ordner der Eclipse-Installation oder verwendet die integrierte Eclipse-Softwareaktualisierung (HELP > SOFTWARE UPDATES). Da sehr viele Abhängigkeiten zu diversen Frameworks existieren, ist der letztere Weg zu empfehlen. Die Softwareaktualisierung prüft vorhandene Abhängigkeiten und lädt alle erforderlichen Bestandteile automatisch über das Internet, so dass eine einwandfreie Funktion des GUI-Builder gewährleistet ist.
Zurückhaltendes Auftreten
Nach der Installation beziehungsweise Aktualisierung ist man zunächst verblüfft, denn man findet den neuen GUI-Builder auch nicht in der Liste der verfügbaren Views. Er tritt zum Beispiel erst dann in Erscheinung, wenn man eine "visuelle Klasse" erzeugt oder eine vorhandene visuelle Klasse (Frame, Panel, Dialog, Window etc.) lädt. Zum Erzeugen von visuellen Klassen gibt es diverse Assistenten, die das Auswählen der Packages und Basisklassen erleichtern. Der Visual Editor arbeitet wie Jigloo und Window Builder Pro mit allen drei Java-GUI-Frameworks zusammen: AWT, Swing und das vom Eclipse-Projekt entwickelte SWT-Framework.
Das Laden einer visuellen Klasse geschieht über OPEN WITH > VISUAL EDITOR. Mit diesem Menübefehl lassen sich auch vorhandene Oberflächen einlesen. Der Visual Editor kann so konfiguriert werden, dass er automatisch GUIs erkennt, die von Borlands Jbuilder und IBMs Visual Age stammen. Über WINDOW > PREFERENCES > JAVA > VISUAL EDITOR gelangt man an weitere Einstellungen zum Erscheinungsbild, zur Codegenerierung und zum Reverse Engineering. Das Reverse Engineering vorhandener Oberflächen funktioniert bis zu einer gewissen Komplexität eines Layouts ausreichend gut. Will man auch komplexe Layouts einlesen, sind Umstrukturierungen notwendig.
Ist eine visuelle Klasse erst einmal im Editor geladen, erscheint auch eine Palette mit Javabeans, aus denen die benötigten Widgets ausgewählt und zu einer Oberfläche arrangiert werden können. Zu diesem Zweck sollte man die neue Javabeans-View verwenden. Sie präsentiert den Aufbau des Widgets beziehungsweise Fensters, das im Editor markiert ist.
Widgets arrangieren
Neue Widgets zieht man vorzugsweise auf diese View und arrangiert das neue Element erst später in der Voransicht. Mehrere Elemente lassen sich über den Befehl CUSTOMIZE LAYOUT eines Kontextmenüs nach verschiedenen Kriterien ausrichten und in der Größe und im Abstand abgleichen.
Das Arrangieren der Widgets lässt durch seine vielfältigen Möglichkeiten kaum Wünsche offen und geht mit einem schnellen Rechner und ausreichend Hauptspeicher auch einigermaßen leicht von der Hand. Der generierte Code ist übersichtlich, frei von proprietären Bestandteilen und angenehm leicht zu lesen. Die Synchronisation zwischen Quelltext und der GUI-Darstellung funktioniert in der Regel gut. Ist der Quelltext aber durch Umstrukturierungen oder gelöschte Elemente kurzzeitig inkonsistent geworden, kommt die Synchronisation des Editors schnell ins Straucheln. Hier hilft nur, entweder die Synchronisation abzuschalten oder den Schwellenwert stark herabzusetzen.
Der Visual Editor hat leider diverse gravierende Mängel. Die Wysiwyg-Ansicht gehört nicht zu den Highlights des Produkts. Aber am ärgerlichsten sind die unzähligen Abstürze, die der GUI-Builder während des Tests verursachte. Sie passieren zum Beispiel im Zusammenhang mit dem Anlegen neuer Swing-Menüs. Hier produzierte der Visual Editor anscheinend Deadlocks bei der Synchronisation. Sie führten dazu, dass die gesamte Entwicklungsumgebung mit "Out of Sync" hängen blieb und nur noch über den Task-Manager gewaltsam beendet werden konnte.
Weiterhin hinterlässt der Visual Editor hin und wieder auch nach ausreichender Synchronisationsphase inkonsistenten Code. Das passiert zum Beispiel beim Löschen nicht mehr benötigter Widgets. Während er für neu angelegte Widgets automatisch die nötigen Importanweisungen ergänzt, funktioniert der umgekehrte Vorgang nicht immer zuverlässig. Entfernt man ein nicht benötigtes Widget, so löscht er die dazu gehörenden Importanweisungen des Öfteren nicht. Das Ergebnis ist, dass die Workbench toten Code moniert.
Ein weiteres großes Problem des Visual Editor ist der Verbrauch an Ressourcen. Selbst mit 512 MB Hauptspeicher lässt sich manchmal nicht mehr flüssig arbeiten. Der GUI-Builder startet diverse virtuelle Maschinen als Subprozesse, die vermutlich - neben dem sicherlich nicht optimierten Code - für den Raubbau an Ressourcen verantwortlich sind. Das Plugin bremst die Leistungsfähigkeit der Eclipse-Workbench so spürbar aus, dass selbst der Start der Entwicklungsumgebung zur Geduldsprobe wird. Summa summarum erscheint die Versionsnummer 1.0, gemessen am Entwicklungsstand dieses Produkts, als stark verfrüht.
Window Builder Pro
Instantiations ist der Hersteller der beiden Produkte SWT Designer und Swing Designer, die man entweder einzeln oder unter dem etwas markigen Namen Window Builder Pro als Bundle erwerben kann. Das Produkt, das in der Version 2.1.0 getestet wurde, ist einfach zu installieren: Man kopiert die Module in den Plugin-Ordner von Eclipse und startet die Workbench neu. Um mit dem Window Builder arbeiten zu können, muss das Produkt allerdings erst beim Hersteller Instantiations freigeschaltet werden. Kostenfrei ist nur eine sehr eingeschränkte Version sowie die Evaluierung der Vollversion.
Nach der Installation erscheint unter den Workbench-Einstellungen (WINDOW > PREFERENCES) ein eigener Unterpunkt namens DESIGNER. Hier können die Codegenerierung, das Aussehen des Designers, Voreinstellungen zum Anlegen neuer Oberflächen sowie das Verhalten des GUI-Builder bei Swing- und SWT-Layouts festgelegt werden. Auch an die Einbindung von Custom-Controls (selbst geschriebenen Widgets) wurde gedacht, jedoch nicht daran, das Reverse Engineering zu steuern.
Die Codegenerierung beschränkt sich wie bei den Konkurrenzprodukten auf einige wenige Einstellungen und könnte noch deutlich erweitert werden. Das Aussehen der Oberfläche des Window Builder kann hingegen nach allen möglichen Arten an den persönlichen Geschmack angepasst werden. Das Anlegen neuer Swing- und SWT-Oberflächen ist ebenfalls konfigurierbar. Hier lassen sich Custom Controls angeben, Look and Feels der Swing-Bibliothek verwalten und Layout-Einstellungen (zum Beispiel das SWT-Formlayout) vornehmen.
Wie schon eingangs angedeutet, unterstützt der Window Builder Pro alle drei momentan verfügbaren Java-GUI-Frameworks: AWT, Swing und das Eclipse-Produkt SWT. Unter Mac OS X ist wie beim Konkurrenzprodukt Jigloo das Entwerfen von Swing-Oberflächen derzeit laut Herstellerangaben aufgrund eines Eclipse-Bugs unmöglich, während der Entwurf der nativen SWT-Oberflächen funktioniert.
Das Laden der entsprechenden Paletten ist abhängig von der Fensterklasse der GUI-Bibliothek, die bearbeitet werden soll. Kommt sie aus dem AWT/Swing-Bereich, zeigt der GUI-Builder nur dazu passende Widgets an, die Auswahl eines SWT-Fensters bewirkt die Anzeige einer SWT-Palette. Das Laden einer visuellen Klasse geschieht wie beim Visual Editor über den Befehl OPEN WITH. Auch Window Builder Pro bietet hierbei mehrere Assistenten an, die es erlauben, die Einstellungen der neuen Klasse komfortabel vorzunehmen.
Die Entwurfsansicht ist einfach zu bedienen und gestattet das Arrangement der Widgets nach allen erdenklichen Möglichkeiten. Die Codegenerierung funktioniert genauso problemlos und erzeugt gut strukturierten, übersichtlichen Quelltext. Die Synchronisation zwischen Quelltext und Entwurfsansicht war eindeutig am besten bei allen drei Produkten und ließ sich auch durch mehrmalige Restrukturierungen nicht aus der Ruhe bringen. Auch der Testmodus der Oberfläche lässt kaum Wünsche offen - im Gegensatz zum Reverse Engineering.
Hier kommt es bei Swing-Oberflächen dazu, dass Elemente nicht korrekt gezeichnet oder Swing-Modelle nicht korrekt mit Live-Daten gefüllt werden. Vermutlich sind diese Schwächen ein Tribut an die mangelhaften Einstellmöglichkeiten für das Reverse Engineering. Trotz dieser Einschränkungen ist der Window Builder alles in allem ein sehr stabiles und auch für professionelle Zwecke geeignetes Produkt. (ue)