- Ghostty टीम ने GTK एप्लिकेशन को पूरी तरह से फिर से लिखा और GObject type system का सक्रिय रूप से उपयोग किया
- इस प्रक्रिया में Zig भाषा के साथ इंटीग्रेशन और Valgrind के जरिए memory issues की जांच ने महत्वपूर्ण भूमिका निभाई
- GObject system अपनाने से पहले की तुलना में memory management और custom widget implementation सरल हो गए
- Valgrind का उपयोग करने के परिणामस्वरूप, Ghostty की memory safety में बड़ा सुधार अनुभव किया गया
- नया Ghostty GTK अब source build का default बन गया है और इसे 1.2 release में शामिल किया जाएगा
परिचय
- Ghostty एक cross-platform terminal emulator है जो macOS, Linux, FreeBSD को सपोर्ट करता है
- हर platform पर native GUI framework का उपयोग करके इसे अलग बनाया गया है
- macOS: Swift और Xcode आधारित large-scale application
- Linux और BSD: GTK आधारित application, X11/Wayland आदि के साथ direct integration
- common core Zig में लिखा गया है और C ABI-compatible API प्रदान करता है
- मौजूदा संरचना में GTK application को फिर से लिखने का कारण मूल PR में देखा जा सकता है
- यह लेख मुख्य रूप से GObject type system के साथ integration और Valgrind से सत्यापित memory issues पर केंद्रित है
GObject type system और Zig
- GTK का उपयोग करने पर मूल रूप से GObject type system के साथ interface करना पड़ता है
- पहले GObject system से बचते हुए reference counting के बिना Zig objects और GObject objects के lifecycle को सीधे मिलाने की कोशिश की गई, लेकिन बार-बार memory release ठीक से न होने की समस्या आई
- उदाहरण: Zig की तरफ की memory free हो गई, लेकिन GTK की memory अभी भी जीवित थी, या इसका उल्टा बार-बार हुआ
- यह approach केवल correctness की समस्या नहीं थी, बल्कि GTK की खास सुविधाओं (event signals, property binding, actions) का उपयोग भी कठिन बना देती थी
- एक ठोस उदाहरण में config struct को reload करते समय उससे जुड़े सभी GUI elements को एकसमान तरीके से update होना चाहिए था, लेकिन यह प्रक्रिया जटिल और त्रुटिपूर्ण थी
- अब Zig
Config struct को wrap करने वाले reference-counted GhosttyConfig GObject से इसे manage किया जाता है, और property change notifications के जरिए बदलाव पूरे application में स्वाभाविक रूप से फैल जाते हैं
- custom GObject widgets बनाना भी आसान हो गया, जिससे Blueprint जैसी आधुनिक GTK UI technologies का उपयोग संभव हुआ
- हाल में Blueprint अपनाने से GTK titlebar tabs, animated bell border जैसी नई सुविधाएँ जोड़ना आसान हुआ
Valgrind, GTK, और Zig
- पूरे development process में Valgrind की मदद से memory leaks, undefined memory access जैसी समस्याओं की व्यवस्थित जांच की गई
- GTK application पर Valgrind चलाना कठिन है, और इसके लिए बड़े suppression files की जरूरत पड़ती है (80% GTK खुद, बाकी 3rd party libraries और GPU drivers)
- बार-बार की गई जांच से ऐसे जटिल memory bugs पहले ही पकड़े जा सके जो केवल कुछ स्थितियों में ही सामने आते हैं
- उदाहरण: अगर GObject
WeakRef को ठीक से initialize न किया जाए, तो target object बाद में free होने पर undefined memory access होता है, जिसे Valgrind ने पहले ही पकड़ लिया
- वास्तविक अनुभव में, Zig codebase के अंदर कुल केवल 2 issues (1 leak, 1 undefined access) मिले, और वे भी 3rd party C API integration के दौरान हुए
- Zig के debug allocators और Valgrind integration features भी प्रभावी साबित हुए
- बाकी मिले memory issues अधिकतर C API boundaries और GObject system के जटिल lifecycle management से जुड़े थे
- निष्कर्षतः जटिल libraries के C API को सुरक्षित रूप से इस्तेमाल करने के लिए Valgrind जैसे tools जरूरी हैं
- Zig की memory safety को सहारा देने वाली सुविधाएँ केवल सैद्धांतिक चर्चा तक सीमित नहीं हैं, बल्कि व्यावहारिक project experience में भी प्रभावी साबित हुईं
निष्कर्ष
- यह Ghostty के GUI हिस्से को पांचवीं बार शुरुआत से फिर से बनाने का अनुभव था
- GLFW, macOS SwiftUI, macOS AppKit+SwiftUI, Linux GTK (procedural), Linux GTK+GObject type system के क्रम में
- बार-बार के rewrite process में हर बार नए सबक और तकनीकी विकास मिले
- इस अनुभव का कुछ हिस्सा macOS project में भी लागू करने की योजना है
- Ghostty GTK system maintainers के सक्रिय सहयोग पर भी जोर दिया गया
- नया फिर से लिखा गया Ghostty GTK एप्लिकेशन अब source build का default बन गया है, और इसे 1.2 stable release में लागू किया जाएगा
अभी कोई टिप्पणी नहीं है.