- El equipo de Ghostty reescribió por completo la aplicación GTK y aprovechó activamente el sistema de tipos GObject
- En este proceso, la integración con el lenguaje Zig y la verificación de problemas de memoria con Valgrind jugaron un papel importante
- Al adoptar el sistema GObject, se simplificaron más que antes la gestión de memoria y la implementación de widgets personalizados
- Al usar Valgrind, comprobaron en la práctica que la seguridad de memoria de Ghostty mejoró considerablemente
- El nuevo Ghostty GTK ya se convirtió en la opción predeterminada para compilar desde el código fuente y está previsto que se incluya en la versión 1.2
Introducción
- Ghostty es un emulador de terminal multiplataforma compatible con macOS, Linux y FreeBSD
- Se distingue por usar frameworks GUI nativos en cada plataforma
- macOS: aplicación de gran escala basada en Swift y Xcode
- Linux y BSD: aplicación basada en GTK, con integración directa con X11/Wayland, etc.
- El núcleo compartido está escrito en Zig y ofrece una API compatible con C ABI
- Para conocer el motivo de la reescritura de la aplicación GTK dentro de la estructura anterior, puede consultarse el PR original
- Este texto se centra especialmente en la integración con el sistema de tipos GObject y en los problemas de memoria verificados con Valgrind
El sistema de tipos GObject y Zig
- Al usar GTK, la estructura exige interactuar de forma predeterminada con el sistema de tipos GObject
- En el pasado intentaron evitar el sistema GObject y hacer coincidir manualmente el ciclo de vida entre objetos Zig sin conteo de referencias y objetos GObject, pero una y otra vez surgieron problemas de liberación incorrecta de memoria
- Ejemplo: la memoria del lado de Zig ya se había liberado, pero la del lado de GTK seguía viva, o ocurría la situación contraria
- Este enfoque no solo generaba problemas de corrección, sino que también dificultaba usar funciones propias de GTK (señales de eventos, binding de propiedades, acciones)
- Un ejemplo concreto fue que, al recargar la estructura de configuración (
config), todos los elementos GUI conectados debían actualizarse de forma consistente, pero ese proceso era complejo y propenso a errores
- Ahora se gestiona mediante un
GhosttyConfig GObject con conteo de referencias que envuelve la estructura Config de Zig, y las notificaciones de cambio de propiedades propagan los cambios de manera natural por toda la aplicación
- También se volvió más fácil crear widgets GObject personalizados, lo que permite usar tecnologías modernas de UI para GTK como Blueprint
- Recientemente, con la adopción de Blueprint, resultó más sencillo introducir nuevas funciones como pestañas en la barra de título de GTK y bordes animados para la campana
Valgrind, GTK y Zig
- Durante todo el proceso de desarrollo se validaron de forma sistemática, con Valgrind, problemas como fugas de memoria y accesos a memoria no definida
- Revisar una aplicación GTK con Valgrind es complicado, y requiere un gran volumen de archivos de suppressions (80% corresponde al propio GTK, y el resto a librerías de terceros y drivers GPU)
- Gracias a las verificaciones repetidas, fue posible descubrir de antemano errores de memoria complejos que solo ocurrían en ciertos casos
- Ejemplo: si no se inicializa correctamente un
WeakRef de GObject, cuando el objeto objetivo se libera más adelante puede producirse un acceso a memoria no definida; Valgrind permitió detectarlo antes
- En la experiencia real, los problemas dentro del codebase de Zig fueron solo 2 en total (1 fuga, 1 acceso no definido), y aun esos ocurrieron durante la integración con APIs C de terceros
- También quedó demostrada la efectividad del asignador de depuración de Zig y de sus funciones de integración con Valgrind
- La mayoría de los demás problemas de memoria detectados provenían de los límites con APIs C y de la compleja gestión del ciclo de vida en el sistema GObject
- En conclusión, para usar con seguridad la API C de librerías complejas, se necesitan herramientas como Valgrind
- Las funciones de apoyo a la seguridad de memoria de Zig demostraron su efectividad no solo en lo teórico, sino también a través de experiencia empírica en proyectos reales
Conclusión
- Esta fue la quinta vez que rehacen desde cero la parte GUI de Ghostty
- GLFW, macOS SwiftUI, macOS AppKit+SwiftUI, Linux GTK (procedimental), Linux GTK+sistema de tipos GObject
- En el proceso de reescritura iterativa, cada vez obtuvieron nuevas lecciones y crecimiento técnico
- Planean aplicar parte de esta experiencia también al proyecto de macOS
- También destacan la colaboración activa del equipo de mantenimiento del sistema GTK de Ghostty
- La aplicación Ghostty GTK recién reescrita ya se convirtió en la opción predeterminada para compilar desde el código fuente, y se aplicará en la versión estable 1.2
Aún no hay comentarios.