Ghostty schreibt die GTK-Anwendung neu

• Das Ghostty-Team hat die GTK-Anwendung vollständig neu geschrieben und das GObject-Typsystem aktiv genutzt
• Dabei spielten die Integration mit der Programmiersprache Zig und die Überprüfung von Speicherproblemen mit Valgrind eine wichtige Rolle
• Durch die Einführung des GObject-Systems wurden Speicherverwaltung und die Implementierung benutzerdefinierter Widgets gegenüber bisher vereinfacht
• Der Einsatz von Valgrind zeigte aus praktischer Erfahrung, dass sich die Speichersicherheit von Ghostty deutlich verbessert hat
• Das neue Ghostty GTK ist nun der Standard für Builds aus dem Quellcode und soll in Release 1.2 enthalten sein

---

Einleitung

• Ghostty ist ein plattformübergreifender Terminal-Emulator mit Unterstützung für macOS, Linux und FreeBSD
• Für jede Plattform nutzt es ein natives GUI-Framework als Unterscheidungsmerkmal
  • macOS: umfangreiche Anwendung auf Basis von Swift und Xcode
  • Linux und BSD: GTK-basierte Anwendung mit direkter Integration in X11/Wayland usw.
  • Der gemeinsame Kern ist in Zig geschrieben und stellt eine API mit C-ABI-Kompatibilität bereit
• Warum die GTK-Anwendung in der bisherigen Struktur neu geschrieben wurde, kann im ursprünglichen PR nachgelesen werden
• Dieser Beitrag konzentriert sich insbesondere auf die Anbindung an das GObject-Typsystem sowie auf mit Valgrind verifizierte Speicherprobleme

GObject-Typsystem und Zig

• Wer GTK verwendet, muss strukturell mit dem GObject-Typsystem und seinen Interfaces arbeiten
• Früher wurde versucht, das GObject-System zu umgehen und den Lebenszyklus von Zig-Objekten ohne Reference Counting und GObject-Objekten direkt aufeinander abzustimmen, doch dabei traten wiederholt Probleme mit nicht korrekt freigegebenem Speicher auf
  • Beispiel: Der Speicher auf Zig-Seite war bereits freigegeben, während der Speicher auf GTK-Seite noch lebte, oder umgekehrt
• Dieser Ansatz erschwerte nicht nur die Korrektheit, sondern auch die Nutzung GTK-spezifischer Funktionen wie Event-Signale, Property Binding und Actions
• Ein konkretes Beispiel war das Neuladen der Config-Struktur: Alle verbundenen GUI-Elemente mussten dabei konsistent aktualisiert werden, was komplex und fehleranfällig war
  • Heute wird dies als reference-counted GhosttyConfig GObject verwaltet, das die Zig-Config-Struktur umhüllt; Benachrichtigungen über Property-Änderungen propagieren Änderungen nun auf natürliche Weise durch die gesamte Anwendung
• Auch das Erstellen benutzerdefinierter GObject-Widgets wurde einfacher, sodass moderne GTK-UI-Technologien wie Blueprint genutzt werden können
  • In letzter Zeit wurde mit der Einführung von Blueprint die Umsetzung neuer Funktionen wie GTK-Tabs in der Titelleiste und animierte Bell-Ränder erleichtert

Valgrind, GTK und Zig

• Während des gesamten Entwicklungsprozesses wurde Valgrind eingesetzt, um Speicherlecks, Zugriffe auf undefinierten Speicher und ähnliche Probleme systematisch zu prüfen
• Die Prüfung einer GTK-Anwendung mit Valgrind ist anspruchsvoll und erfordert große Suppression-Dateien (80 % für GTK selbst, der Rest für Third-Party-Bibliotheken und GPU-Treiber)
• Durch wiederholte Prüfungen konnten komplexe Speicherfehler, die nur in bestimmten Fällen auftreten, frühzeitig entdeckt werden
  • Beispiel: Wird ein GObject-WeakRef nicht korrekt initialisiert, kann es später beim Freigeben des Zielobjekts zu Zugriffen auf undefinierten Speicher kommen; Valgrind erkannte dies im Voraus
• In der Praxis gab es im Zig-Codebestand insgesamt nur zwei Probleme (ein Leak, ein undefinierter Zugriff), und selbst diese traten bei der Anbindung an eine Third-Party-C-API auf
  • Auch Zigs Debug-Allocator und die Valgrind-Integrationsfunktionen haben ihre Wirksamkeit belegt
• Die übrigen gefundenen Speicherprobleme stammten überwiegend von den C-API-Grenzen und der komplexen Lebenszyklusverwaltung im GObject-System
  • Das Fazit lautet: Um die C-API komplexer Bibliotheken sicher zu nutzen, sind Werkzeuge wie Valgrind erforderlich
• Die unterstützenden Funktionen von Zig für Speichersicherheit erwiesen sich nicht nur in theoretischen Diskussionen, sondern auch in konkreter Projekterfahrung als wirksam

Fazit

• Dies war das fünfte Mal, dass der GUI-Teil von Ghostty von Grund auf neu erstellt wurde
  • In der Reihenfolge: GLFW, macOS SwiftUI, macOS AppKit+SwiftUI, Linux GTK (prozedural), Linux GTK + GObject-Typsystem
• Aus dem wiederholten Rewrite wurden jedes Mal neue Erkenntnisse und technisches Wachstum gewonnen
  • Teile dieser Erfahrung sollen auch auf das macOS-Projekt übertragen werden
• Hervorgehoben wird außerdem die aktive Zusammenarbeit des Wartungsteams für das Ghostty-GTK-System
• Die neu geschriebene Ghostty-GTK-Anwendung ist nun der Standard für Source-Builds und soll mit dem offiziellen Release 1.2 eingeführt werden