Entwicklungsgeschichte des Graphical Editing Frameworks

GEF – Past, Present, and Future

Alexander Nyßen

© Shutterstock.com / zhangyang13576997233

Kaum ein Eclipse-Projekt darf behaupten, auf eine ähnlich lange und bewegte Geschichte zurückzublicken wie die Plattform selbst. Das Graphical Editing Framework (GEF) gehört zweifelsohne dazu. So darf auch ohne Einbeziehung der IBM-internen Vorgeschichte in diesem Jahr der zehnte Geburtstag des Projekts gefeiert werden. Anlass genug, einmal einen kurzen Blick auf die Geschichte, die Ereignisse der letzten Jahre und die zukünftige Entwicklung des Projekts zu werfen.

Seit 2002 fester Bestandteil des Eclipse-Ökosystems, deckt das Graphical-Editing-Framework-Projekt (GEF) das graphische Visualisieren und Editieren auf der Basis von SWT beziehungsweise dem Eclipse Workbench UI ab. Hierfür bietet GEF drei Komponenten:

  • Draw2d, ein auf SWT aufsetzendes Framework für 2-D-Rendering und Layouting, das prinzipiell auch eigenständig außerhalb von Eclipse (rein auf der Basis von SWT) eingesetzt werden kann (Abb. 1).
  • GEF (MVC), ein interaktives Model-View-Controller-Framework, das es erlaubt, SWT-basierte Baumeditoren oder Draw2d-basierte graphische Editoren für das Eclipse Workbench UI zu erstellen (Abb. 2).
  • Zest, ein Visualisierungs-Toolkit auf der Basis von SWT und Draw2d zur Erstellung graphischer Sichten mit automatischem oder teilautomatischem Layout für das Eclipse Workbench UI (Abb. 3).
Abb. 1: Draw2d-Klassendiagramm, Beispiel

Abb. 1: Draw2d-Klassendiagramm, Beispiel

Abb. 2: GEF-Logic-Beispieleditor

Abb. 2: GEF-Logic-Beispieleditor

Abb. 3: PDE Dependency View, realisiert mit Zest

Abb. 3: PDE Dependency View, realisiert mit Zest

Dabei wird Draw2d wohl vor allem als Visualisierungstechnologie der beiden anderen GEF-Komponenten, GEF (MVC) und Zest eingesetzt, die für das Erstellen graphischer Sichten und Editoren im Eclipse-Umfeld den Quasistandard vorgeben. Dabei findet GEF (MVC), wenngleich es auch in einigen Eclipse-basierten graphischen Editoren zum direkten Einsatz kommt, wohl vor allem in seiner Eigenschaft als Basistechnologie für GMF und Graphiti weite Verbreitung.

Past

Geschichtlich gesehen haben alle drei Komponenten gewissermaßen einen „Migrationshintergrund“. Während Draw2d und GEF (MVC) etwa seit 2000 originär durch IBM entwickelt wurden (Stichwort: etools) und bereits 2002 als GEF 1.0 gemeinsam den Weg unter das Dach der Eclipse Foundation fanden, erblickte Zest im universitären Kontext (University of Victoria, Kanada) das Licht der Welt und kam, zwischenzeitlich Bestandteil des Mylyn-Projekts, 2007 zu GEF dazu, wo es im Rahmen des 3.4-Releases erstmals als Bestandteil veröffentlicht wurde.

Seitdem besteht das Projekt in seiner jetzigen Form. Dabei lag der Fokus seit dem Release von GEF 3.0 2004 vor allem darauf, den zahlreichen Anwendern ein möglichst stabiles API zur Verfügung zu stellen und das vorhandene durch kompatible Bugfixes und Enhancements zu verbessern. Seit 2004 hat es daher keine inkompatiblen Änderungen des API mehr gegeben, es wurde aber durch kompatible Änderungen weiter ergänzt. So wurde beispielsweise bei Draw2d und GEF (MVC) im Rahmen des 3.6-Releases bessere Unterstützung für das Clipping von Connections und die Interaktion im Zusammenhang mit geschachtelten View Ports (Abb. 4) hinzugefügt. Im Rahmen des 3.7-Releases wurde die plattformübergreifende Interoperabilität, insbesondere für die Mac-OS-X-Plattform, deutlich verbessert und eine Reihe von (abwärtskompatiblen) Refactorings umgesetzt.

Abb. 4: Scrollable Selection Feedback (Quelle: [3])

Abb. 4: Scrollable Selection Feedback (Quelle)

Trotz der kontinuierlichen Erweiterungen kommt das bisherige Vorgehen langsam aber sicher an seine Grenzen. Während ein stabiles API seinen Nutzern einerseits eine hohe Verlässlichkeit garantiert, hemmt es auf der anderen Seite Innovationen, denn nicht alle Weiterentwicklungen lassen sich unter Beibehaltung der API-Kompatibilität sinnvoll umsetzen. Viele über die Zeit angehäufte Schwächen des bestehenden API lassen sich ebensowenig ausmerzen.

Aus diesem Grund wurde bei Zest bereits ab 2010 parallel zur Wartung des 1.x API (hier wurden nur noch Bugfixes, aber keine Features mehr umgesetzt) mit der Erarbeitung eines neuen 2.0 API im Rahmen einer vorläufigen (engl. provisional) Zest2-Komponente begonnen. Da hier explizit die Weiterentwicklung des API im Vordergrund steht, wird bis zur finalen Graduierung im Unterschied zu Zest 1.x kein stabiles API garantiert. Aus dem gleichen Grund unterwirft sich Zest2 auch nicht dem jährlichen Releasezyklus von Eclipse, werden die Quellen in einem eigenen Git Repository verwaltet und werden Snapshot-Releases nicht im Rahmen des Simultaneous-Releases veröffentlicht, sondern getrennt im Eclipse Marketplace.

Present

Mit dem für Juni 2012 anvisierten Juno-Release werden Draw2d und GEF (MVC) 3.x in Version 3.8, Zest 1.x in Version 1.4 vorliegen. Neben ein paar kleineren Bugfixes und Erweiterungen liegt für das aktuelle Release der Schwerpunkt dabei vor allem darauf, die Projektinfrastruktur, das heißt das Source Repository und die Build-Infrastruktur, auf den technologisch neuesten Stand zu bringen. So wurde die alte, etwas angestaubte und noch auf der Common Modeling Build Infrastructure basierende Lösung bereits durch eine Tycho/Hudson-basierte ersetzt. Dadurch sind nun sämtliche GEF Builds, auch die nächtlichen CI Builds, transparent für alle Nutzer auf hudson.eclipse.org zugänglich. Zusätzlich wird auch das Quellcode-Respository in Kürze von CVS auf Git umgestellt. Damit ist GEF dann für die in Zukunft standardisierte Common Build Infrastructure von Eclipse und den darauf aufsetzenden Long Term Support bestens aufgestellt.

Bei Zest2 wurde in den letzten beiden Jahren vor allem an einer Vereinfachung des Layout-API und neuen Layoutalgorithmen gearbeitet. Zusätzlich wurde eine Unterstützung für das Visualisieren von Graphviz-DOT-basierten Beschreibungen integriert, wie in Abbildung 4 dargestellt. Im Juno-Entwicklungszeitraum wurde neben einer verbesserten Unterstützung für individuelle Router und Figuren zusätzlich eine Word-Cloud-Visualisierung integriert.

Abb. 5: Zest-Dot-Editor (Quelle)

Abb. 5: Zest-Dot-Editor (Quelle)

Ähnlich wie bei Zest ist auch für Draw2d und GEF (MVC) in den letzten Jahren eine Erneuerung des API zunehmend in den Fokus der Aufmerksamkeit gerückt, da das Ziel ein stabiles, abwärtskompatibles API anzubieten mit dem Wunsch, neue Features zu integrieren und alte Schwächen des API beseitigen zu können, mehr und mehr kollidierte. Um beide Ziele gleichermaßen verfolgen zu können, bot es sich an, wie bei Zest2 den Weg einer vorläufigen Komponente zu gehen. So kann ein neues stabiles API entwickelt werden, ohne bisherige Nutzer den dauerhaften Migrationsaufwänden eines noch evolvierenden API aussetzen zu müssen. Folgerichtig wurde auch für Draw2d und GEF (MVC) nach dem Indigo-Release mit GEF4 eine vorläufige Komponente zur parallelen Entwicklung des zukünftigen API ins Leben gerufen.

Im Rahmen des Juno-Entwicklungszeitraums wurde hierfür zunächst die notwendige Projektinfrastruktur aufgesetzt (Tycho/Hudson-basierter CI Build, Git Repository), und es wurde mit der Entwicklung eines Geometry API begonnen, das auf Basis der bisherigen Draw2d-Geometrieklassen neu konzipiert wurde. Als initialer „Nukleus“ soll dieses API mit dem Juno-Release in einer ersten Version vorliegen.

Future

Für die Zeit nach dem Juno-Release ist geplant, die weiteren Teile der Draw2d und GEF (MVC) 3.x API zu GEF4 zu überführen und die dann erhaltene Codebasis parallel zu den 3.x-Versionen zu modernisieren. Zusätzlich dazu soll auch die Codebasis der bisher unabhängig entwickelten Zest2-Komponente zu GEF4 überführt werden. Damit werden die beiden vorläufigen Komponenten zu einer einzigen verschmolzen. Neben dem Anliegen, den Nutzern von Draw2d und GEF (MVC) 3.x und Zest 1.x auch weiterhin ein stabiles API zur Verfügung zu stellen, liegt damit der zukünftige Fokus vor allem auf der Erneuerung des Projekts.

Im Detail stehen hierbei neben einem generellen „Aufräumen“ und Umstrukturieren des über die Jahre gewachsenen API eine ganze Reihe weiterer Themen auf der „Wunschliste“, die schon seit Langem in den Foren und in Bugzilla diskutiert werden, aber aufgrund der API-Beschränkungen in Bezug auf Kompatibilität bisher nicht umsetzbar waren. Dazu zählt beispielsweise eine Unterstützung für Rotationen und für B-Splines und eine einfachere Integration von nativen SWT-Widgets, aber auch die Adaption neuer Eclipse-3.x Platform-APIs, beispielsweise zur Unterstützung von Multi-Touch-Gesten. Nicht zuletzt wird auch die direkte Unterstützung der neuen Eclipse 4.x Application Platform stark nachgefragt.

Entscheidend für die Umsetzung dieser Umstrukturierungen und Erweiterungen wird dabei insbesondere sein, inwieweit die GEF-Community sich in Zukunft aktiv in die Modernisierungsanstrengungen einbringen wird. Die bisherigen Erfahrungen aus Zest2 und erstes Feedback zu GEF4 lassen hier einiges erwarten. Man darf also gespannt in die Zukunft schauen.

Aufmacherbild: New residential construction home metal framing against a blue sky via Shutterstock.com / Urheberrecht: zhangyang13576997233

Geschrieben von
Alexander Nyßen
Alexander Nyßen
Dr. Alexander Nyßen arbeitet als Principal Engineer für die itemis AG in Lünen, wo er unter anderem als Projektleiter und Softwarearchitekt mit der Entwicklung Eclipse-basierter Werkzeuglösungen betraut ist. Er ist seit fünf Jahren Committer des Eclipse Graphical Editing Frameworks und leitet das Projekt seit 2013.
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.