Suche
GEF4 – Mission to Mars

Die neuen GEF4-Komponenten in Eclipse Mars

Alexander Nyßen

© istockphoto /CreativeGraphikArts

Kaum ein anderes Eclipse-Projekt kann auf eine ähnlich lange Geschichte zurückblicken wie das Graphical Editing Framework (GEF). Seit 2002 ist GEF fester Bestandteil des Eclipse-Ökosystems, und seit der Einführung des Simultaneous Releases im Jahr 2006 gab es keines ohne GEF-Beteiligung. Auch beim Mars-Release im Juni dieses Jahres wird GEF selbstverständlich nicht fehlen. Dieses Mal aber ist etwas besonders: Das Release wird den ersten Snapshot der seit 2010 entwickelten neuen GEF4-Komponenten beinhalten.

Das Eclipse Graphical Editing Framework unterstützt die Erstellung grafischer Anwendungen im Rahmen von Eclipse und ist damit quasi die Basis für alles „Grafische“, das unter dem Dach der Eclipse Foundation zu finden ist. Neben zahlreichen direkten Nutzern setzen unter anderem auch die beiden großen Rahmenwerke für grafische Modellierung, GMF und Graphiti auf GEF als Basistechnologie. Bis dato bietet GEF drei Produktivkomponenten:

  • Draw2d (3.x) ist ein leichtgewichtiger Aufsatz zu SWT und ergänzt die hierin fehlende Unterstützung für 2-D-Visualisierung (vergleichbar mit Java 2D im AWT-Kontext).
  • GEF (MVC) (3.x) stellt ein interaktives Model-View-Controller-Rahmenwerk zur Verfügung, mit dem sich SWT/Draw2d-basierte grafische Editoren im Kontext der Eclipse Workbench erstellen lassen.
  • Zest (1.x) bietet Unterstützung für die Visualisierung von Graphstrukturen mittels SWT/Draw2d und JFace, unter anderem ergänzt um automatisches Layout.

Wie auch in den vergangenen Jahren werden die drei Produktivkomponenten für das Mars-Release in neuen Minor-Revisionen (Draw2d/GEF (MVC) 3.10.0 bzw. Zest 1.6.0) verfügbar sein.

Dabei beschränken sich die Änderungen auf Bugfixes und kleine Ergänzungen des bestehenden API. Seit 2004 ist es gelebte Philosophie, dass auf inkompatible Änderungen verzichtet wird. Mittlerweile bedeutet das allerdings auch, dass die bestehenden drei Produktivkomponenten nicht mehr aktiv weiterentwickelt, sondern nur noch gewartet werden.

The Story behind GEF4

Aufgrund der selbst auferlegten Zwänge hinsichtlich der API-Kompatibilität, und weil die Codebasis – insbesondere die Rendering-Technologie Draw2d – langsam aber sicher in die Jahre gekommen ist, arbeitet das Projektteam seit 2010 parallel zur Wartung der drei Produktivkomponenten an einer grundlegenden Erneuerung. Begonnen wurden die Arbeiten im Rahmen von Zest 2.x. Dabei war das verfolgte Ziel, das seit 2007 nur abwärtskompatibel geänderte API von Zest 1.x noch einmal vollständig zu überarbeiten, ohne dabei die Nutzer von Zest 1.x zu einer direkten Migration zu zwingen. Die Arbeiten fanden dementsprechend in einem separaten Repository und parallel zur Wartung der Zest-1.x-Produktivkomponente statt. An SWT und Draw2d als Rendering-Technologien wurde dabei festgehalten. Neben einigen Refactorings und Ergänzungen wurden in diesem Zuge aber auch zwei grundlegend neue Features ergänzt: eine Unterstützung für das Erstellen von Tag Clouds (Cloudio) sowie ein Xtext-basierter Editor und ein Zest-2.x-basierter Viewer für das Editieren und Anzeigen von Graphviz-DOT-Dateien (Dot4Zest).

Fast parallel zu Zest 2.x wurde seit 2011 auch an der Erneuerung der beiden anderen, bereits seit 2004 ebenfalls nur abwärtskompatibel weiterentwickelten Produktivkomponenten Draw2d und GEF (MVC) gearbeitet – in Anlehnung an die Bezeichnung „e4“ für die 4. Generation der Eclipse-Plattform unter dem Namen „GEF4“, Zunächst stand dabei die Realisierung eines hinreichend mächtigen, eigenen Geometrie-API im Vordergrund, als Alternative zu der von Draw2d in diesem Zusammenhang stark eingeschränkten Funktionalität. Die Arbeiten wurden bis 2012 weitestgehend abgeschlossen. Im Anschluss daran wurde schließlich mit der Ablösung der Rendering-Bestandteile von Draw2d durch JavaFX und entsprechende projektspezifische Ergänzungen (GEF4-FX) begonnen, sowie 2013 auch an einer Ablösung von GEF (MVC) durch ein grundlegend neu konzipiertes Model-View-Controller-Rahmenwerk (GEF4 MVC).

Bereits 2012 waren die Ziele von Zest 2.x und GEF4 dahingehend übereingebracht worden, die bisherigen Produktivkomponenten insgesamt durch einen gemeinsamen, vereinheitlichten Ansatz abzulösen. Dabei wurde schließlich GEF4 als Sammelbegriff für alle Aktivitäten im Rahmen der Erneuerung etabliert und die Infrastruktur des Projekts vereinheitlicht (nur noch ein Repository, ein integrierter CI-Build und eine Update Site). Die schon bestehende Zest-2.x-Codebasis wurde in den GEF4-Namensraum überführt, basierte intern aber nach wie vor auf SWT und Draw2d. Eine komplette Eigenständigkeit von GEF4 war daher aufgrund der Abhängigkeiten zu der Draw2d-Produktivkomponente zunächst noch nicht gegeben.

Mission to Mars

Seit 2013 liegt das primäre Augenmerk deshalb darauf, GEF4 als eigenständiges Rahmenwerk neben den bisherigen drei Produktivkomponenten zu etablieren. Dies ist das erklärte Ziel, sozusagen die Mission für Mars. Hierfür galt und gilt es, die durch Übernahme der Zest-2.x-Codebasis eingeführten Abhängigkeiten zu Draw2d vollständig zu eliminieren und die funktionale Lücke gegenüber GEF 3.x so weit wie möglich zu schließen. Denn basierend auf JavaFX als moderner Alternative zu Draw2d sollen durch GEF4 nicht nur viele neue Funktionen ermöglicht werden. Der bisherige Funktionsumfang der Produktivkomponenten muss ebenso realisiert werden können. Allerdings soll es im Rahmen von GEF4 keine direkte Unterstützung für SWT-basierte Tree-Editoren mehr geben.

Der Abschluss der Zest-2.x-zu-GEF4-Migration, also das vollständige Eliminieren aller GEF-3.x-Abhängigkeiten, wurde mit dem Mars-M6-Meilenstein (API Freeze) planmäßig abgeschlossen. Bis dahin wurde die Zest-2.x-Codebasis vollständig auf Basis anderer GEF4-Komponenten neu implementiert und setzt jetzt auch durchgehend auf JavaFX zur Visualisierung. Sie ist zudem intern deutlich sauberer modularisiert und profitiert von zahlreichen neuen Funktionen, die im Rahmen von GEF4 umgesetzt wurden, beispielsweise von Gestensteuerung und stufenlosem Zoom.

Das Schließen der funktionalen Lücke zwischen GEF4 und den weiteren Bestandteilen von GEF 3.x wird seit 2014 parallel dazu weiter intensiv verfolgt. Viele der wesentlichen Funktionen von Draw2d und GEF (MVC) 3.x lassen sich schon jetzt mit direkter GEF4-Unterstützung umsetzen. Wo eine solche Unterstützung noch fehlt, lässt sich dies oft bereits durch die Mächtigkeit von JavaFX und die Flexibilität des neuen MVC-Rahmenwerks kompensieren. Der Einsatz von JavaFX anstelle von Draw2d bietet hier einen großen Gewinn, da viele der in Draw2d nur umständlich oder gar nicht zu realisierenden Funktionen oft schon allein mithilfe von JavaFX und ohne GEF4-spezifische Unterstützung umgesetzt werden können.

Darüber hinaus wurden gegenüber den bisherigen Produktivkomponenten auch bereits einige neue Funktionen ergänzt, beispielsweise Unterstützung für gestenbasierte Interaktionen oder für das einfache Anwenden von affinen Transformationen, beispielsweise zur Rotation von Shapes.

Bis zum Erreichen des Mars-M7-Meilensteins (Feature Freeze) wird vor allem noch das Abrunden der jetzigen Funktionalität sowie Bugfixing im Fokus stehen, danach bis zum finalen Releasetermin vor allem der Aufbau einer umfassenden Entwicklerdokumentation.

Im Ergebnis werden die neuen GEF4-Komponenten beim Mars-Release erstmalig in Form eines 0.1.0-Snapshots verfügbar sein. Die gewählte Versionsnummer deutet dabei an, dass das API noch als vorläufig (engl.: „provisional“) zu betrachten ist und inkompatible Änderungen für nachstehende Releases ausdrücklich nicht ausgeschlossen werden können.

Die GEF4-Komponenten im Überblick

Zest wurde erst 2007 zu GEF überführt; zu diesem Zeitpunkt war das API für Draw2d und GEF (MVC) aber bereits fixiert. Aufgrund der Vorgaben hinsichtlich API-Kompatibilität wurde dies auch nachträglich nicht mehr korrigiert. Während bei den bisher angebotenen Produktivkomponenten die Modularisierung also eher historisch motiviert war, wurde bei GEF4 im Gegenzug sehr viel Wert auf eine technisch motivierte, saubere Modularisierung gelegt. Dies äußert sich so, dass bei GEF4 nun neun Komponenten angeboten werden, die alle durchweg kleiner und besser gekapselt sind als die bisherigen drei Produktivkomponenten. Sie sind in Abbildung 1 im Überblick dargestellt.

Abb. 1: Die GEF4-Komponenten in der Übersicht (FX = JavaFX, UI = SWT/JFace/Eclipse UI)

Abb. 1: Die GEF4-Komponenten in der Übersicht (FX = JavaFX, UI = SWT/JFace/Eclipse UI)

Das Spektrum reicht dabei von generischen Bibliothekskomponenten, die auch abseits grafischer Applikationen genutzt werden können (GEF4 Common, GEF4 Geometry) über entsprechende Rahmenwerkslösungen im Kontext von grafischen Applikationen (GEF4 FX, GEF4 MVC, GEF4 Graph, GEF4 Layout, GEF4 Zest) bis hin zu Komponenten, die direkt für den Endbenutzer verfügbare Werkzeuge bereitstellen (GEF4 DOT, GEF4 Cloudio).

Allen Komponenten ist gemein, dass Rendering-Technologie-abhängige Anteile klar von unabhängigen getrennt wurden. Genauso sind Anteile, die auch außerhalb der Eclipse Workbench nutzbar sind, eindeutig von solchen unterschieden, die von SWT/JFace bzw. der Eclipse Workbench abhängen. Beispielsweise besteht die GEF4-MVC-Komponente intern aus vier Modulen: MVC, MVC.FX, MVC.UI sowie MVC.FX.UI. Die Suffixe „FX“ und „UI“ werden im Rahmen von GEF4 generell genutzt, um jeweils Abhängigkeiten zu JavaFX bzw. zu SWT/JFace/Eclipse Workbench anzuzeigen. Damit soll zum einen erreicht werden, dass Kernabstraktionen auch beim Einsatz anderer Rendering-Technologien als JavaFX genutzt werden können. Andererseits kann GEF4 damit auch für das Erstellen von grafischen Applikationen außerhalb der Eclipse Workbench eingesetzt werden, beispielsweise für webbasierte Editoren.

Im Einzelnen werden im Rahmen des Mars-Releases die folgenden Komponenten verfügbar sein (in Klammern stehen jeweils die einzelnen Module der Komponenten):

Common stellt allgemeine Basisabstraktionen bereit, die potenziell von allen anderen GEF4-Komponenten genutzt werden können. Dies schließt zum Beispiel ein erweitertes IAdaptable-Pattern ein. Das Pattern wird im Rahmen von GEF4 MVC und GEF4 Zest auch intensiv genutzt, um grafische Applikationen sehr flexibel – und unter Zuhilfenahme von Dependency Injection – konfigurieren zu können. Es bietet beispielsweise aber auch weitergehende Unterstützung für den Umgang mit Properties oder auch Utilities für das Arbeiten mit Java Reflection.

Geometry (Geometry, Geometry.Convert.SWT, Geometry.Convert.FX) stellt unterschiedliche Abstraktionen (euklidisch, projektiv, planar) für geometrische Berechnungen im zweidimensionalen Raum bereit. Die Komponente erlaubt dabei durchgehend Double-basierte Rechenoperationen, wobei Rechenungenauigkeiten auf der Basis ungenauer Vergleiche kompensiert werden. Erwähnenswert ist, dass neben den „üblichen“ geometrischen Abstraktionen im Rahmen der planaren Geometrie auch direkte Unterstützung für den Umgang mit Bézierkurven n-ten Grades, Polybéziers und Curved Polygons angeboten wird. Zudem werden Konvertierungsfunktionen zu den Geometrierepräsentationen von SWT und JavaFX bereitgestellt, sodass entsprechende Konvertierungen leicht durchgeführt werden können.

FX (FX, FX.UI) bietet Ergänzungen zu JavaFX, die im Rahmen von grafischen Applikationen benötigt werden. Dies beinhaltet beispielsweise Implementierungen für visuelle Anker, für Dekorationen und für Connections, die durch das FX-Modul bereitgestellt werden. In Kombination mit JavaFX dient dieses somit als Ersatz für die bisherige Draw2d-Produktivkomponente.  Zusätzlich erweitert das FX.UI-Modul die bereits durch JavaFX selbst zur Verfügung gestellte SWT-Integration um das dort fehlende Weiterleiten von Gestenereignissen und ermöglicht es darüber hinaus, auch SWT-Widgets mittels eines entsprechenden Adapters (FXControlAdapter) in den JavaFX-Szenengrafen zu integrieren (sofern JavaFX im Rahmen der SWT-Integration eingesetzt wird). Damit kann dann nicht nur ein JavaFX-Szenengraf innerhalb eines SWT-Canvas dargestellt werden. Auch die eventuell unterhalb des SWT-Canvas vorhandenen SWT-Widgets können nun gemeinsam mit JavaFX-Nodes im Szenengrafen gelayoutet werden (Abb. 2). So lassen sich zum Beispiel innerhalb der Eclipse Workbench SWT-Widgets einfach in der Visualisierung mit JavaFX-gerenderten Anteilen kombinieren, zum Beispiel um im Rahmen der GEF4-MVC-Komponente JavaFX-basierte ColorPicker in SWT-basierte Editoren der PropertiesView zu integrieren. Es ließe sich aber beispielsweise auch im Rahmen eines grafischen JavaFX-basierten Eclipse-Editors einsetzen, um die Palette nach wie vor auf Basis von SWT-Buttons zu realisieren.

Abb. 2: GEF4-„FXControlAdapter“-Beispiel

Abb. 2: GEF4-„FXControlAdapter“-Beispiel

MVC (MVC, MVC.UI, MVC.FX, MVC.FX.UI) ist ein Model-View-Controller-Framework, das zum Aufbau grafischer Sichten und Editoren genutzt werden kann. Es bildet das Herzstück von GEF4 und kann eigenständig für das Erstellen beliebiger grafischer Applikationen genutzt werden, findet aber auch innerhalb der Visualisierungskomponente GEF4 Zest und im Graph Viewer der GEF4-DOT-Komponente als Basistechnologie Anwendung.

Gegenüber der bisherigen Produktivkomponente GEF (MVC) unterscheidet sich GEF4 MVC in mehrfacher Hinsicht. Zum einen wurden – wie bei allen übrigen GEF4-Komponenten – die vom Rendering-Toolkit abhängigen Anteile durch eine entsprechende Aufteilung in Module klar von den unabhängigen getrennt. Gleiches gilt für Abhängigkeiten zu SWT/JFace bzw. der Eclipse Workbench. Damit ist GEF4 MVC nicht mehr wie GEF (MVC) 3x nur auf den Einsatz grafischer Editoren im Umfeld der Eclipse 3.x Workbench beschränkt, sondern kann insbesondere auch für die Realisierung grafischer Anwendungen außerhalb von Eclipse genutzt werden, beispielsweise für webbasierte grafische Editoren. Eine Adaption an andere Rendering-Toolkits ist auf Basis der MVC- und MVC.UI-Module ebenfalls möglich.

Zusätzlich wird durch den breiten Einsatz des Adapter-Patterns und von Dependency Injection eine sehr flexible Konfigurier- und Anpassbarkeit der Komponente erreicht. So kann beispielsweise eine bestimmte Visualisierung oder ein Verhaltensaspekt sehr leicht ausgetauscht werden, auch zur Laufzeit.

Hinsichtlich der für den Endanwender sichtbaren Features punktet GEF4 MVC gegenüber GEF 3.x vor allem aufgrund des Wegfalls der durch SWT/Draw2d auferlegten Beschränkungen. So gibt es jetzt eine direkte Unterstützung für gestenbasierte Interaktionen, beispielsweise bei Panning, dem nun ein Infinite-Canvas-Ansatz zugrunde liegt, oder bei dem nun stufenlos möglichen Zoom. Darüber hinaus können nun beliebige affine Transformationen, damit insbesondere auch Rotationen, direkt angewendet werden. Alle Benutzerinteraktionen werden zudem im Sinne eines Live-Feedback-Ansatzes durch direktes Manipulieren der Visualisierung umgesetzt, sodass das Routing einer Connection beispielsweise noch während des Bewegens eines Wegpunkts live angepasst wird. Insgesamt profitiert GEF4 MVC dabei stark vom Einsatz einer modernen Rendering-Technologie, die es im Gegensatz zu Draw2d ermöglicht, Visualisierungen in hoher Qualität und Genauigkeit zu erzeugen, wie in Abbildung 3 gezeigt.

Gegenüber GEF 3.x ist die Funktionalität in Teilen aber noch eingeschränkt. So gibt es beispielsweise noch keine primäre Unterstützung für Features wie „Direct Editing“ und „Snap-to-Geometry“ für das Anzeigen einer Palette oder von Linealen, oder auch für Druck- bzw. Imageexport. Eine direkte Unterstützung für das Anlegen von Shapes und Connections fehlt ebenfalls noch (Das Anlegen von Shapes wurde bislang nur in einem Beispiel umgesetzt, das Anlegen von Connections noch nicht). Eine solche Unterstützung soll aber noch im Rahmen des Mars-Releases, d. h. bis zum M7-Meilenstein, ergänzt werden. Die übrigen offenen Punkte sollen ebenso möglichst kurzfristig angegangen werden. Dies wird aber im Rahmen des Mars-Releases nicht mehr möglich sein.

Abb. 3: GEF4-MVC-Logo-Beispiel

Abb. 3: GEF4-MVC-Logo-Beispiel

Graph stellt ein einfaches Modell zur Verfügung, das zur Repräsentation von gerichteten Graphen genutzt werden kann. Es wird im Rahmen der Zest-Visualisierung als Eingabemodell verwendet und als internes Datenmodell der GraphViz-DOT-Import-/Export-Funktionalität, die durch die GEF4-DOT-Komponente angeboten wird. Mittelfristig soll GEF4 Graph auch als Standardnotationsmodell für das einfache Erstellen von grafischen Editoren auf Basis von GEF4 MVC eingesetzt werden können. Bislang spielt es nur im Rahmen von GEF4 Zest diese Rolle. Darin wird es insbesondere an GEF4 Layout adaptiert, um das Eingabemodell in diesem Kontext auch automatisch zu layouten.

Layout stellt Schnittstellen zur Anbindung von Layoutalgorithmen sowie zugehörige Standardimplementierungen (Spring, Grid, Radial, Sugiyama, Tree, Horizontal Shift, SpaceTree, Composite) bereit. Es wird im Rahmen der Zest-Visualisierung für automatisches Layout verwendet, kann aber prinzipiell auch unabhängig von Zest im Rahmen grafischer Applikationen genutzt werden. Momentan gibt es hierfür noch keine direkte Unterstützung im Rahmen von GEF4 MVC, da dort bis dato keinerlei Annahmen über das zu visualisierende Modell gemacht werden. Mittelfristig soll dies aber als Ergänzung bereitgestellt werden. Bei GEF4 Zest hingegen ist das unterliegende Modell auf GEF4 Graph festgelegt. Außerdem ist geplant, die Layoutschnittstellen enger an die durch das KIELER-Framework angebotenen Abstraktionen anzugleichen. KIELER-Layoutalgorithmen können so möglichst einfach auch mit GEF4 integriert werden.

Zest (Zest.FX, Zest.FX.UI) ist ein Rahmenwerk zur Graphvisualisierung. Basierend auf GEF4 MVC erlaubt es Zest.FX, ein GEF4-Graph-basiertes Datenmodell zu visualisieren und über eine Integration mit GEF4 Layout auch automatisiert zu layouten, wie in Abbildung 4 ersichtlich wird. Die von Zest.FX angebotenen End-User-Features entsprechen dabei im Wesentlichen den von GEF4 MVC bereitgestellten. Ergänzt werden sie aber durch modellabhängige Interaktionen, beispielsweise durch das Navigieren von genesteten Graphstrukturen unter Anwendung von Zoom.

Unter der Haube stellt Zest.FX im Wesentlichen GEF4-MVC-basierte Controller und einfache Visualisierungen für die von GEF4 Graph definierten Abstraktionen (Graph, Node, Edge) bereit. Diese können durch CSS Styling angepasst oder durch eigene JavaFX-basierte Implementierungen ausgetauscht werden. Zudem adaptiert Zest.FX zwischen GEF4 Graph und GEF4 Layout, um die durch GEF4 Layout angebotenen Layoutalgorithmen nutzen zu können.

Neben dem Einsatz außerhalb von Eclipse lässt sich GEF4 Zest über eine vom Zest.FX.UI-Modul bereitgestellte View nahtlos in die Eclipse Workbench integrieren. Dabei kann alternativ über einen ZestContentViewer das Eingabemodell auch indirekt durch ein JFace-basiertes API über ContentProvider bereitgestellt werden, die Visualisierung ist entsprechend über Label-, Tooltip-, Font-, oder ColorProvider zu beeinflussen.

Abb. 4: GEF4-Zest-Graph-Beispiel

Abb. 4: GEF4-Zest-Graph-Beispiel

Cloudio (Cloudio.UI) bietet Unterstützung für das Visualisieren von Tag Clouds. Dazu werden ein entsprechendes SWT-Widget (TagCloud) sowie ein JFace-basierter TagCloudViewer angeboten, mit deren Hilfe Tag Clouds innerhalb eigener grafischer Applikationen dargestellt werden können. Darüber hinaus bietet Cloudio eine View an, mit der ein Endbenutzer Tag Clouds anhand einer Eingabetextdatei im Rahmen der Eclipse Workbench visualisieren und als Bild exportieren kann (Abb. 5).

Im Unterschied zu den übrigen für Visualisierung eingesetzten GEF4-Komponenten bietet Cloudio allerdings noch keine Möglichkeit, eine Tag Cloud mittels JavaFX zu rendern. Mittelfristig soll diese Funktionalität ergänzt werden. Im Rahmen des Mars-Releases wird sie aber noch nicht zur Verfügung stehen.

Abb. 5: GEF4 Cloudio Tag Cloud View

Abb. 5: GEF4 Cloudio Tag Cloud View

Mission accomplished?

Insgesamt wird mit dem Mars-Release ein erster wichtiger Meilenstein hin zur vollständigen Runderneuerung von GEF erreicht sein. Auch wenn das API von GEF4 zunächst nur als „provisional“ angeboten wird und zumindest teilweise noch eine Lücke zu der durch GEF 3.x angebotenen Funktionalität besteht, gibt es nun erstmals offiziell eine Alternative zu den nur noch gewarteten, aber nicht mehr weiterentwickelten bisherigen Produktivkomponenten.

Damit ist die Veröffentlichung dieses ersten Snapshot-Releases in jedem Fall ein großer Schritt. Allerdings wird das Projektteam weiter intensiv daran arbeiten müssen, die Ablösung von GEF 3.x voranzutreiben. Das Tempo, mit dem dies geschehen kann, wird sicher auch stark davon abhängen, wie aktiv sich die Community in die Weiterentwicklung einbringen wird. Dennoch: Der Anfang ist gemacht, das Schwerste sollte also geschafft sein. Damit geht eine fast fünfjährige Reise zwar noch nicht zu Ende, trotzdem lässt sich aber wohl schon jetzt sagen: Mission accomplished!

Verwandte Themen:

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

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: