Ghostty GTKアプリケーションを書き直し

(mitchellh.com)

1 ポイント投稿者 GN⁺ 2025-08-16 | まだコメントはありません。 | WhatsAppで共有

序論

GhosttyはmacOS、Linux、FreeBSDをサポートするクロスプラットフォームのターミナルエミュレータ
各プラットフォームごとにネイティブGUIフレームワークを使用して差別化している
- macOS: SwiftおよびXcodeベースの大規模アプリケーション
- LinuxおよびBSD: GTKベースのアプリケーションで、X11/Waylandなどと直接統合
- 共通コアはZigで書かれており、C ABI互換APIを提供する
既存構造でGTKアプリケーションを書き直した理由は、原文のPRを参照可能
本文では、GObject型システムとの連携とValgrindで検証したメモリ問題に重点的に触れる

GTKを使う場合、基本的にGObject型システムとインターフェースする構造になる
過去にはGObjectシステムを避けつつ、参照カウントのないZigオブジェクトとGObjectオブジェクトのライフサイクルを直接合わせようとしたが、メモリ解放が正しく行われない問題が繰り返し発生した
- 例: Zig側のメモリは解放されたのにGTK側のメモリはまだ生きている、あるいはその逆の状況が繰り返された
このアプローチは正しさの問題だけでなく、**GTK固有機能（イベントシグナル、プロパティバインディング、アクション）**の利用も難しくした
具体例として、設定(config)構造体をリロードする際に接続されたすべてのGUI要素が一貫して更新される必要があったが、この過程は複雑でエラーも多かった
- 現在はZigのConfig構造体をラップする参照カウント付きGhosttyConfig GObjectとして管理しており、プロパティ変更通知によってアプリケーション全体に自然に変更が伝播する
カスタムGObjectウィジェットの作成も容易になり、BlueprintなどのモダンなGTK UI技術が利用可能になった
- 最近ではBlueprintの導入により、GTKタイトルバータブ、アニメーションするベル枠線などの新機能を導入しやすくなった

開発過程全体でValgrindを使い、メモリリークや未定義メモリアクセスなどの問題を体系的に検証した
GTKアプリケーションのValgrind検査は難しく、大量のsuppressionファイルが必要だった（80%はGTK自体、残りはサードパーティライブラリおよびGPUドライバ）
繰り返しの検査により、特定のケースでのみ発生する複雑なメモリバグを事前に発見できた
- 例: GObject WeakRefを正しく初期化しないと、対象オブジェクトが後で解放される際に未定義メモリアクセスが発生するが、Valgrindで事前に検出できた
実際の経験では、**Zigコードベース内部の問題は合計2件（リーク1件、未定義アクセス1件）**にすぎず、それもサードパーティC APIとの連携過程で発生したものだった
- Zigのデバッグ用アロケータおよびValgrind統合機能の有効性も証明された
その他に見つかったメモリ問題の大半は、C API境界とGObjectシステムの複雑なライフサイクル管理に起因していた
- 結論として、複雑なライブラリのC APIを安全に使うにはValgrindのようなツールが必要
Zigのメモリ安全性支援機能は理論的な議論にとどまらず、実証的なプロジェクト経験でも効果が確認された

今回はGhosttyのGUI部分を5回目としてゼロから作り直した経験だった
- GLFW、macOS SwiftUI、macOS AppKit+SwiftUI、Linux GTK（手続き型）、Linux GTK+GObject型システムの順
繰り返しの再実装の過程で、毎回新しい教訓と技術的成長を得てきた
- 今回の経験をmacOSプロジェクトにも一部適用する計画
Ghostty GTKシステム保守チームの積極的な協力も強調した
新たに書き直されたGhostty GTKアプリケーションはすでにソースビルドのデフォルトとなっており、1.2正式リリースに適用される予定