Réécriture de l’application GTK de Ghostty

• L’équipe de Ghostty a entièrement réécrit l’application GTK en exploitant activement le système de types GObject
• Dans ce processus, l’intégration avec le langage Zig et la vérification des problèmes mémoire avec Valgrind ont joué un rôle important
• L’adoption du système GObject a simplifié la gestion de la mémoire et l’implémentation de widgets personnalisés par rapport à l’existant
• L’usage de Valgrind a permis de constater une nette amélioration de la sûreté mémoire de Ghostty
• Le nouveau Ghostty GTK est devenu la base par défaut pour les builds depuis le code source et sera inclus dans la version 1.2

---

Introduction

• Ghostty est un émulateur de terminal multiplateforme prenant en charge macOS, Linux et FreeBSD
• Il se distingue en utilisant des frameworks GUI natifs selon chaque plateforme
  • macOS : application de grande taille basée sur Swift et Xcode
  • Linux et BSD : application basée sur GTK, avec intégration directe à X11/Wayland, etc.
  • Le cœur commun est écrit en Zig et fournit une API compatible C ABI
• La raison de la réécriture de l’application GTK dans l’architecture précédente peut être consultée dans la PR d’origine
• Cet article se concentre surtout sur l’intégration avec le système de types GObject ainsi que sur les problèmes mémoire vérifiés avec Valgrind

Le système de types GObject et Zig

• Lorsqu’on utilise GTK, l’architecture impose d’interfacer de base avec le système de types GObject
• Par le passé, l’équipe évitait le système GObject et tentait d’aligner directement le cycle de vie des objets Zig sans comptage de références et des objets GObject, mais cela provoquait à répétition des problèmes de libération mémoire incorrecte
  • Exemple : la mémoire côté Zig était libérée alors que la mémoire côté GTK vivait encore, ou l’inverse
• Cette approche posait non seulement des problèmes de correction, mais rendait aussi difficile l’usage des fonctionnalités propres à GTK (signaux d’événement, liaison de propriétés, actions)
• Un exemple concret concernait le rechargement de la structure de configuration (config) : tous les éléments GUI liés devaient être mis à jour de manière cohérente, un processus complexe et sujet aux erreurs
  • Désormais, cela est géré via un GhosttyConfig GObject avec comptage de références qui encapsule la structure Zig Config, et les notifications de changement de propriété propagent naturellement les modifications à l’ensemble de l’application
• La création de widgets GObject personnalisés est aussi devenue plus simple, ce qui permet d’utiliser des technologies UI GTK modernes comme Blueprint
  • Récemment, l’introduction de Blueprint a facilité l’ajout de nouvelles fonctions comme les onglets dans la barre de titre GTK et la bordure animée de la cloche

Valgrind, GTK et Zig

• Tout au long du développement, Valgrind a servi à vérifier systématiquement les fuites mémoire, les accès à de la mémoire non définie et d’autres problèmes du même type
• L’inspection Valgrind d’une application GTK est délicate et nécessite de gros fichiers de suppression (80 % pour GTK lui-même, le reste pour des bibliothèques tierces et les pilotes GPU)
• Des vérifications répétées permettent de détecter à l’avance certains bugs mémoire complexes qui ne surviennent que dans des cas particuliers
  • Exemple : si un WeakRef GObject n’est pas correctement initialisé, un accès à de la mémoire non définie peut survenir plus tard lorsque l’objet cible est libéré ; Valgrind a permis de le repérer en amont
• D’après l’expérience réelle, les problèmes internes au code Zig n’ont été qu’au nombre de 2 au total (1 fuite, 1 accès non défini), et même ceux-là sont apparus lors de l’intégration avec des API C tierces
  • L’allocateur de débogage de Zig et ses fonctions d’intégration avec Valgrind ont également démontré leur efficacité
• Les autres problèmes mémoire découverts provenaient majoritairement des frontières avec les API C et de la gestion complexe du cycle de vie dans le système GObject
  • En conclusion, pour utiliser en sécurité l’API C de bibliothèques complexes, des outils comme Valgrind sont nécessaires
• Les fonctions d’assistance à la sûreté mémoire de Zig ont montré leur efficacité non seulement dans les discussions théoriques, mais aussi dans une expérience de projet concrète

Conclusion

• Il s’agit de la cinquième fois que la partie GUI de Ghostty est reconstruite depuis zéro
  • Dans l’ordre : GLFW, macOS SwiftUI, macOS AppKit+SwiftUI, Linux GTK (procédural), Linux GTK + système de types GObject
• À chaque réécriture, ce processus itératif a apporté de nouveaux enseignements et une progression technique
  • Une partie de cette expérience devrait aussi être appliquée au projet macOS
• La collaboration active de l’équipe chargée de la maintenance du système Ghostty GTK est également mise en avant
• La nouvelle application Ghostty GTK réécrite est désormais la valeur par défaut pour les builds depuis les sources et sera adoptée dans la version 1.2 stable