Warum moderne Multi-Monitor-Setups neue UI-Konzepte in der Eclipse (öffnet in neuem Tab)-Architektur erfordern – und wie eine praktikable Lösung für Vector Informatik entstand, die über die Eclipse Plattform vielen Software-Anbietern und tausenden Produkten zugutekommt. Ein Blick hinter die Kulissen zeigt, wie Vector und Yatta die Eclipse Platform für mehr Stabilität, Abwärtskompatibilität und Benutzerfreundlichkeit weiterentwickelt haben.

Vector Informatik und PREEvision: Komplexe E/E-Systeme im Fokus

Vector ist ein international tätiger Anbieter von Software-Werkzeugen und -Komponenten für die Entwicklung eingebetteter elektronischer Systeme (Embedded Systems), mit Schwerpunkt auf der Automobilindustrie. Rund 4.500 Mitarbeiter unterstützen Kunden weltweit bei der Entwicklung, Vernetzung und Absicherung von elektrisch/elektronischen Systemen.

Das Produkt zum Systemdesign in der Toollandschaft von Vector ist PREEvision. Die Software basiert auf der Eclipse Rich Client Platform (RCP) und dient der durchgängigen Modellierung von software-definierten, cyber-physikalischen Systemen – von den Anforderungen über die Systemarchitektur bis hin zum Kabelbaum. PREEvision wird zurzeit ausschließlich für Windows entwickelt und sowohl von Kunden als auch in der Produktentwicklung von Vector selbst genutzt.

Ausgangslage: UI-Skalierung stieß an technische Grenzen

Mit der Verbreitung hochauflösender Monitore und heterogener Multi-Monitor-Setups wuchsen die Anforderungen an die Benutzeroberfläche von PREEvision. Unterschiedliche Pixeldichten und monitor-spezifische Zoom-Einstellungen unter Windows führten dazu, dass die UI-Skalierung bei Anwendungsstart zwar korrekt für den Hauptmonitor gesetzt, beim Verschieben auf andere Monitore jedoch unscharf dargestellt wurde.

Die Eclipse Platform bot hierfür keine zufriedenstellende Lösung für die verwendenden Produkte, wie zum Beispiel PREEvision. Die bestehende Softwarearchitektur der UI-Skalierung erwies sich als stark limitierend – sowohl für die Nutzer als auch für die Eigenentwicklung der Eclipse IDE.

Herausforderung: Plattform-Stabilität trifft auf Innovationsbedarf

Die zentrale Herausforderung bestand technisch darin, monitor-spezifische UI-Skalierung in der Eclipse-Plattform zu ermöglichen, ohne bestehende Produkte zu beeinträchtigen. Da Eclipse als Framework für tausende Anwendungen dient, durfte es weder zu Regressionen noch zu API-Brüchen kommen.

Die neue Funktionalität wurde daher bewusst optional und iterativ integrierbar umgesetzt. Ziel war es, Stabilität und Kompatibilität fortlaufend und ohne Unterbrechung zu gewährleisten. Gleichzeitig sollte der Anpassungsaufwand für bestehende Produkte möglichst gering bleiben. Erschwerend kam hinzu, dass grundlegende Designentscheidungen der Plattform – etwa das zugrunde liegende Koordinatensystem – nur eingeschränkt mit monitor-spezifischer Skalierung vereinbar waren und teilweise grundlegend überdacht oder pragmatisch umgangen werden mussten.

Auch organisatorisch stellte das Projekt besondere Anforderungen, denn die Entwicklung erfolgte im Open-Source-Kontext und erforderte eine enge Zusammenarbeit mit Vector und anderen Committern innerhalb des Eclipse-Projekts. Die Entwickler arbeiteten dabei als Team im Verbund und standen in engem fachlichem Austausch mit weiteren Beteiligten, um jeweils transparent und zügig technisch maßgebliche Entscheidungen zu treffen.

Lösung: Monitor-spezifische Skalierung als Open-Source Feature—und neue Browser-Technik für die Eclipse-Plattform

Gemeinsam entwickelten Vector und Yatta eine monitor-spezifische UI-Skalierung für Windows, direkt innerhalb des Eclipse Platform Projects. Diese Skalierung sorgt für eine scharfe, zoom-konforme Darstellung auf allen angeschlossenen Monitoren, insbesondere nach einem Monitor-Wechsel. Die Lösung ist als Standardmodus implementiert, kann bei Bedarf aber auch abgeschaltet werden.

Bei der Gelegenheit wurde die Einbindung von Edge/WebView2 in Eclipse-Produkten erweitert und damit der bisher genutzte Internet Explorer als eingebetteter Browser abgelöst. Bis dahin war in Windows noch der IE der Standard und dieser funktionierte mit einer Monitor-spezifischen Skalierung nicht zufriedenstellend. Zudem wurde das Diagrammframework GEF Classic für pixelgenaues Rendering unter Berücksichtigung der neuen Skalierungslogik angepasst.

Die Umsetzung erfolgte vollständig durch entsprechende Open-Source-Releases; von proprietären, unveröffentlichten Patches haben die Parteien abgesehen. Damit wurde auch die Basis für weitere Eclipse- und damit Open-Source-basierte Software-Produkte wesentlich verbessert.

Ergebnis: Stabiler Standard für Eclipse und PREEvision

Die neue Skalierungsfunktionalität steht mit dem Release von PREEvision 26.0 im Februar 2026 produktseitig zur Verfügung und ist bereits seit September 2025 erfolgreich in einem internen PREEvision-Derivat im Einsatz. Sie ist als Standardeinstellung seit dem Eclipse-Release 2025-06 etabliert und hat sich bereits über mehrere Releases hinweg als stabil erwiesen.

Über die Funktionalität hinaus führt die intensive Feature-Entwicklung zu einer spürbaren Wiederbelebung des Eclipse Widget Toolkits SWT. Für Vector bedeutet das nicht nur zufriedenere Nutzer, sondern auch eine modernisierte technische Basis und vertieftes Know-how für die langfristige Pflege der Eclipse-Plattform als Fundament von PREEvision.

„Die Zusammenarbeit mit Yatta hat es uns ermöglicht, ein lange bestehendes technisches Defizit der Eclipse-Plattform nachhaltig zu lösen. Besonders wertvoll war dabei der konsequente Open-Source-Ansatz: Die neue monitor-spezifische UI-Skalierung ist stabil, abwärtskompatibel und heute als Standard nutzbar – nicht nur für PREEvision, sondern für die gesamte Eclipse-Community.“ —Heiko Klare, Senior Manager Software Development, Vector Informatik GmbH

Ein Blick hinter die Kulissen der Entwicklung

Begleitend zum Projekt veröffentlichte die Redaktion von heise.de bereits im März 2025 einen Fachbeitrag, der die Entstehung der monitor-spezifischen UI-Skalierung aus technischer Sicht beleuchtet. In dem Artikel beschreibt Yatta Software Engineer Amartya „Marty“ Parijat die technisch-architektonischen Grenzen der bestehenden Eclipse-Implementierung, diskutiert verworfene Lösungsansätze und erläutert, warum bestimmte Designentscheidungen erforderlich waren, um Stabilität, Abwärtskompatibilität und Optionalität zu gewährleisten.

Anhand konkreter Beispiele wird nachvollziehbar, wie sich die neuen Mechanismen in SWT und angrenzenden Komponenten auswirken, sowie welche Lehren sich daraus für die Weiterentwicklung großer Open-Source-Plattformen ziehen lassen.

Zum gesamten Fachbeitrag: https://www.heise.de/hintergrund/Eclipse-IDE-Scharf-auf-allen-Monitoren-mit-HiDPI-Darstellung-10326190.html (öffnet in neuem Tab)