1 poin oleh GN⁺ 2025-08-16 | Belum ada komentar. | Bagikan ke WhatsApp
  • Tim Ghostty menulis ulang aplikasi GTK sepenuhnya dan secara aktif memanfaatkan sistem tipe GObject
  • Dalam proses ini, integrasi dengan bahasa Zig dan verifikasi isu memori melalui Valgrind memainkan peran penting
  • Dengan mengadopsi sistem GObject, manajemen memori dan implementasi widget kustom menjadi lebih sederhana dibanding sebelumnya
  • Dengan memanfaatkan Valgrind, mereka merasakan bahwa keamanan memori Ghostty meningkat secara signifikan
  • Ghostty GTK yang baru kini menjadi default untuk build dari source dan dijadwalkan akan masuk ke rilis 1.2

Pendahuluan

  • Ghostty adalah emulator terminal lintas platform yang mendukung macOS, Linux, FreeBSD
  • Ghostty memiliki keunggulan dengan menggunakan framework GUI native di tiap platform
    • macOS: aplikasi besar berbasis Swift dan Xcode
    • Linux dan BSD: aplikasi berbasis GTK, terintegrasi langsung dengan X11/Wayland dan lainnya
    • Core bersama ditulis dalam Zig dan menyediakan API yang kompatibel dengan C ABI
  • Alasan menulis ulang aplikasi GTK dalam struktur sebelumnya dapat dilihat pada PR asli
  • Tulisan ini berfokus pada integrasi dengan sistem tipe GObject serta isu memori yang diverifikasi dengan Valgrind

Sistem tipe GObject dan Zig

  • Saat menggunakan GTK, strukturnya pada dasarnya mengharuskan untuk berinteraksi dengan sistem tipe GObject
  • Di masa lalu, mereka menghindari sistem GObject dan mencoba menyelaraskan sendiri siklus hidup objek Zig tanpa reference counting dan objek GObject, tetapi berulang kali muncul masalah pelepasan memori yang tidak berjalan dengan benar
    • Contoh: memori di sisi Zig sudah dibebaskan, tetapi memori di sisi GTK masih hidup, atau sebaliknya, dan situasi ini terus berulang
  • Pendekatan seperti ini tidak hanya bermasalah dari sisi correctness, tetapi juga menyulitkan penggunaan fitur khas GTK (event signal, property binding, action)
  • Contoh konkretnya, saat me-reload struct konfigurasi (config), semua elemen GUI yang terhubung harus diperbarui secara konsisten, tetapi proses ini rumit dan sering menimbulkan kesalahan
    • Sekarang, ini dikelola sebagai GhosttyConfig GObject dengan reference counting yang membungkus struct Config Zig, sehingga perubahan dapat menyebar secara alami ke seluruh aplikasi melalui notifikasi perubahan properti
  • Pembuatan widget GObject kustom juga menjadi lebih mudah, sehingga teknologi UI GTK modern seperti Blueprint dapat digunakan
    • Baru-baru ini, dengan mengadopsi Blueprint, fitur baru seperti tab titlebar GTK dan bingkai lonceng beranimasi menjadi lebih mudah ditambahkan

Valgrind, GTK, dan Zig

  • Sepanjang proses pengembangan, Valgrind digunakan untuk memverifikasi secara sistematis masalah seperti memory leak dan akses ke memori yang tidak terdefinisi
  • Pemeriksaan Valgrind pada aplikasi GTK cukup rumit, dan memerlukan file suppression dalam jumlah besar (80% untuk GTK sendiri, sisanya untuk library pihak ketiga dan driver GPU)
  • Dengan pemeriksaan berulang, bug memori kompleks yang hanya muncul pada kasus tertentu bisa ditemukan lebih awal
    • Contoh: jika WeakRef milik GObject tidak diinisialisasi dengan benar, akses ke memori tak terdefinisi dapat terjadi ketika objek target dibebaskan nanti, dan ini bisa ditangkap lebih dulu oleh Valgrind
  • Berdasarkan pengalaman nyata, isu di dalam codebase Zig sendiri hanya berjumlah 2 kasus (1 leak, 1 akses tak terdefinisi), dan itu pun terjadi dalam proses integrasi dengan C API pihak ketiga
    • Allocator debug milik Zig dan fitur integrasi dengan Valgrind juga terbukti efektif
  • Isu memori lain yang ditemukan sebagian besar berasal dari boundary C API dan pengelolaan siklus hidup yang kompleks dalam sistem GObject
    • Kesimpulannya, untuk menggunakan C API dari library kompleks dengan aman, diperlukan alat seperti Valgrind
  • Fitur pendukung keamanan memori di Zig terbukti efektif bukan hanya dalam diskusi teoretis, tetapi juga melalui pengalaman proyek yang terverifikasi secara empiris

Kesimpulan

  • Ini adalah pengalaman kelima membangun ulang bagian GUI Ghostty dari nol
    • Secara berurutan: GLFW, macOS SwiftUI, macOS AppKit+SwiftUI, Linux GTK (prosedural), Linux GTK+sistem tipe GObject
  • Dalam proses penulisan ulang yang berulang, setiap kali ada pelajaran baru dan pertumbuhan teknis yang didapat
    • Pengalaman kali ini juga direncanakan untuk sebagian diterapkan pada proyek macOS
  • Kolaborasi aktif dari tim pemelihara sistem Ghostty GTK juga ditekankan
  • Aplikasi Ghostty GTK yang baru ditulis ulang kini telah menjadi default untuk build dari source, dan akan diterapkan pada rilis resmi 1.2

Belum ada komentar.

Belum ada komentar.