015efcf9e5
Surprise, @ghostty-org/gtk! Hopefully a happy one. This PR introduces the boilerplate for a new apprt I'm calling `gtk-ng`. The `gtk-ng` apprt is still GTK, but built up from first principles using the GObject type system, Blueprint files, etc. This will ultimately replace and become `gtk` (the `-ng` suffix will be stripped once we fully replace our existing GTK apprt). In this PR, the `gtk-ng` apprt does nothing more but show a "Hello, Ghostty" GTK window. It doesn't run a terminal, yet. 😄 I want to use this PR to introduce the boilerplate and share my motivations. Since `gtk-ng` and `gtk` are separate apprts, I can PR small, reviewable, and risky changes into `gtk-ng` rather than opening some mega-PR that replaces everything all at once. Simultaneously, we can continue to iterate on and maintain our shipping `gtk` apprt without dealing with conflicts. > [!IMPORTANT] > > To reiterate, this PR doesn't change anything about our `gtk` apprt. Builds by default will still use the `gtk` apprt and we can continue to build both `gtk` and `gtk-ng` side by side (actually, a very important property until we can be confident we've reached parity). ## A Refactor, Not a Rewrite The primary goal of this apprt is to _primarily_ be a **refactor, not a rewrite.** As much as possible, I'm going to be bringing over a lot of the same logic from `gtk` as long as it fits and makes sense, but applying it to our new structure and lifecycle. For example in this PR you can see how we handle style manager, cgroups, etc. and how that fits within the new `GhosttyApplication` class. Our GTK apprt from a business logic standpoint is _pretty damn good_ and _pretty damn stable_. There's no need to rock that boat and try to rewrite core logic such as input handling, X11/Wayland stuff, etc. It just has to be massaged into the new structure. ## Why? **Object-oriented, reference-counted systems are good for UI, actually.** Experience iterating on the non-trivial macOS application has really reaffirmed that OOP and memory managed systems are really, really nice for GUI. I'm not a huge OOP fan in general, but it fits GUI patterns extremely well. And memory management of any form (GC, Ref Counts, etc.) is important in GUIs where "objects" are handed off to various owners at different times, the most concrete example being: splits moving across windows or into an undo management system. **Blueprint and UI definitions have been a success.** These were introduced in an incremental way into the `apprt/gtk` (thanks ❤️ ) and have been great. But our existing non-GObject system makes it hard to go _all in_ on them, e.g. bindings. Moving to a full GObject-based system will let us fully adopt this. **`zig-gobject` is good and stable.** This didn't really exist when we started the GTK apprt (see the long history below). Since adopting it, its proven to be an excellent, stable dependency. I'm ready to go all-in on it. **Memory management has been a challenge.** Our mix of GObject and non-GObject lifetimes within the GTK apprt has consistently been a source of memory leaks at best and crashes at worst. For example, `Window`, `Surface`, `Tab`, etc. have weird lifetimes that we try to pair alongside their GTK counterparts and its nasty and I don't think anyone who maintains this will disagree. By representing all of these concepts as GObject or Widget subclasses, we'll align all their lifetimes as expected. **Personally, I've grown a lot, particularly from working on the macOS side.** I think all of us as programmers can agree that _programming in multiple languages makes us better programmers_. Similarly, building the macOS app has shown me patterns and techniques that would make our GTK-based application better. I'd like to bring those to the GTK side. (Likewise, I've improved the macOS side from periods of time working on the GTK side and I suspect that might happen again!) ### Longer Background It's easy to rewrite. And I think our maintainers know that I'm not a fan of rewrites. I think its the wrong decision most of the time. It is easy to look at "legacy" code (especially code you didn't write yourself), be disgusted, and think you can rewrite it all better. But no engineer sets out to create technical debt, and I think its worth respecting how and why some code came to be before embarking on something new. This section does that. #### The Beginning Ghostty started as a pure Zig-based GLFW app, with no concept of "apprt". It was Linux-only, and X11-only. At some point, I refactored out the "apprt" system in order to introduce GTK4 (GTK4 came before any macOS work). For the initial GTK4 work, I decided to just call into the libgtk C APIs directly. There were various contributing factors for this decision: 1. Zig was _rapidly_ changing, and we were on nightly Zig. This was around the Zig 0.11, 0.12 times. Taking on new Zig dependencies was really dangerous because Zig nightly could break all of us at any moment. 2. [`zig-gobject`](https://github.com/ianprime0509/zig-gobject) was brand new and unstable. Given point 1, I discarded it and did straight C APIs. 3. Ghostty itself was very simple. We didn't support tabs, we didn't support splits. We were still primarily concerned with making the terminal stable. We weren't on the "native UI" part of our roadmap quite yet. This was our initial foray in that direction. 4. On a personal level, I hadn't done real native GUI programming in a _long_ time (on any platform). Recall the macOS apprt didn't exist yet, either. Jumping into "plain old Zig" with "plain old C APIs" was a practical, no-nonsense way for me to get going. Given all this, I still believe I (it was only me then) made the right decision for the time. #### Zig, GTK apprt Stabilization Eventually, the factors listed above changed: (1) Zig stabilized more and Ghostty moved to stable Zig for various reasons. (2) `zig-gobject` became a mature, stable library. (3) Ghostty the application has become increasingly complex (in a good way, we support a ton of awesome "platform UI" features). Socially, the @ghostty-org/gtk subsystem team was created and is filled with people who are experienced with GTK and Linux in general. This team introduced more idiomatic GTK concepts into the project such as blueprint files, a `zig-gobject` migration, and more. The @ghostty-org/gtk subsystem maintainers have done an awesome job iterating on this change within the existing `apprt/gtk`. This has been often frustrating, but it was a pragmatic approach to move us towards the future and let us ship new features into GTK4 to pursue our platform UI goals. #### GUI Maturity We're now at the point where the core Ghostty terminal (the core, terminal emulation) is incredibly stable. We don't have exact numbers but we can confidently assume its used by thousands of people everyday for real, professional work. As such, most of the changes within the 1.1 and 1.2 cycle have been at the apprt/GUI layer, introducing significantly more complexity: localization, more X11/Wayland integrations, more text to native elements like the process exit overlay, etc. I recently rewrote the entire terminal, tab, and split data model in the macOS app to give us a better foundation for future functionality, and to improve our memory management story (surface leaks were a common problem before, and they haven't happened since since the lifetime of a surface is so much more obvious). This also let me iterate more quickly on more features such as undo/redo, but will also more easily enable things like split titles, merging splits into tabs/windows, etc. (not done yet). I think its time for this type of change within the GTK apprt as well. We have the collective real world experience and we've put in the work in iteration to understand what needs to be done.
Ghostty
Fast, native, feature-rich terminal emulator pushing modern features.
About
·
Download
·
Documentation
·
Developing
About
Ghostty is a terminal emulator that differentiates itself by being fast, feature-rich, and native. While there are many excellent terminal emulators available, they all force you to choose between speed, features, or native UIs. Ghostty provides all three.
In all categories, I am not trying to claim that Ghostty is the best (i.e. the fastest, most feature-rich, or most native). But Ghostty is competitive in all three categories and Ghostty doesn't make you choose between them.
Ghostty also intends to push the boundaries of what is possible with a terminal emulator by exposing modern, opt-in features that enable CLI tool developers to build more feature rich, interactive applications.
While aiming for this ambitious goal, our first step is to make Ghostty one of the best fully standards compliant terminal emulator, remaining compatible with all existing shells and software while supporting all of the latest terminal innovations in the ecosystem. You can use Ghostty as a drop-in replacement for your existing terminal emulator.
For more details, see About Ghostty.
Download
See the download page on the Ghostty website.
Documentation
See the documentation on the Ghostty website.
Roadmap and Status
The high-level ambitious plan for the project, in order:
| # | Step | Status |
|---|---|---|
| 1 | Standards-compliant terminal emulation | ✅ |
| 2 | Competitive performance | ✅ |
| 3 | Basic customizability -- fonts, bg colors, etc. | ✅ |
| 4 | Richer windowing features -- multi-window, tabbing, panes | ✅ |
| 5 | Native Platform Experiences (i.e. Mac Preference Panel) | ⚠️ |
| 6 | Cross-platform libghostty for Embeddable Terminals |
⚠️ |
| 7 | Windows Terminals (including PowerShell, Cmd, WSL) | ❌ |
| N | Fancy features (to be expanded upon later) | ❌ |
Additional details for each step in the big roadmap below:
Standards-Compliant Terminal Emulation
Ghostty implements enough control sequences to be used by hundreds of testers daily for over the past year. Further, we've done a comprehensive xterm audit comparing Ghostty's behavior to xterm and building a set of conformance test cases.
We believe Ghostty is one of the most compliant terminal emulators available.
Terminal behavior is partially a de jure standard (i.e. ECMA-48) but mostly a de facto standard as defined by popular terminal emulators worldwide. Ghostty takes the approach that our behavior is defined by (1) standards, if available, (2) xterm, if the feature exists, (3) other popular terminals, in that order. This defines what the Ghostty project views as a "standard."
Competitive Performance
We need better benchmarks to continuously verify this, but Ghostty is generally in the same performance category as the other highest performing terminal emulators.
For rendering, we have a multi-renderer architecture that uses OpenGL on Linux and Metal on macOS. As far as I'm aware, we're the only terminal emulator other than iTerm that uses Metal directly. And we're the only terminal emulator that has a Metal renderer that supports ligatures (iTerm uses a CPU renderer if ligatures are enabled). We can maintain around 60fps under heavy load and much more generally -- though the terminal is usually rendering much lower due to little screen changes.
For IO, we have a dedicated IO thread that maintains very little jitter
under heavy IO load (i.e. cat <big file>.txt). On benchmarks for IO,
we're usually within a small margin of other fast terminal emulators.
For example, reading a dump of plain text is 4x faster compared to iTerm and
Kitty, and 2x faster than Terminal.app. Alacritty is very fast but we're still
around the same speed (give or take) and our app experience is much more
feature rich.
Note
Despite being very fast, there is a lot of room for improvement here.
Richer Windowing Features
The Mac and Linux (build with GTK) apps support multi-window, tabbing, and splits.
Native Platform Experiences
Ghostty is a cross-platform terminal emulator but we don't aim for a least-common-denominator experience. There is a large, shared core written in Zig but we do a lot of platform-native things:
- The macOS app is a true SwiftUI-based application with all the things you would expect such as real windowing, menu bars, a settings GUI, etc.
- macOS uses a true Metal renderer with CoreText for font discovery.
- The Linux app is built with GTK.
There are more improvements to be made. The macOS settings window is still a work-in-progress. Similar improvements will follow with Linux.
Cross-platform libghostty for Embeddable Terminals
In addition to being a standalone terminal emulator, Ghostty is a
C-compatible library for embedding a fast, feature-rich terminal emulator
in any 3rd party project. This library is called libghostty.
This goal is not hypothetical! The macOS app is a libghostty consumer.
The macOS app is a native Swift app developed in Xcode and main() is
within Swift. The Swift app links to libghostty and uses the C API to
render terminals.
This step encompasses expanding libghostty support to more platforms
and more use cases. At the time of writing this, libghostty is very
Mac-centric -- particularly around rendering -- and we have work to do to
expand this to other platforms.
Crash Reports
Ghostty has a built-in crash reporter that will generate and save crash
reports to disk. The crash reports are saved to the $XDG_STATE_HOME/ghostty/crash
directory. If $XDG_STATE_HOME is not set, the default is ~/.local/state.
Crash reports are not automatically sent anywhere off your machine.
Crash reports are only generated the next time Ghostty is started after a crash. If Ghostty crashes and you want to generate a crash report, you must restart Ghostty at least once. You should see a message in the log that a crash report was generated.
Note
Use the
ghostty +crash-reportCLI command to get a list of available crash reports. A future version of Ghostty will make the contents of the crash reports more easily viewable through the CLI and GUI.
Crash reports end in the .ghosttycrash extension. The crash reports are in
Sentry envelope format. You can
upload these to your own Sentry account to view their contents, but the format
is also publicly documented so any other available tools can also be used.
The ghostty +crash-report CLI command can be used to list any crash reports.
A future version of Ghostty will show you the contents of the crash report
directly in the terminal.
To send the crash report to the Ghostty project, you can use the following CLI command using the Sentry CLI:
SENTRY_DSN=https://e914ee84fd895c4fe324afa3e53dac76@o4507352570920960.ingest.us.sentry.io/4507850923638784 sentry-cli send-envelope --raw <path to ghostty crash>
Warning
The crash report can contain sensitive information. The report doesn't purposely contain sensitive information, but it does contain the full stack memory of each thread at the time of the crash. This information is used to rebuild the stack trace but can also contain sensitive data depending when the crash occurred.
Developing Ghostty
See the documentation on the Ghostty website for
building Ghostty from a source tarball.
Building Ghostty from a Git checkout is very similar, except you want to
omit the -Doptimize flag to build a debug build, and you may require
additional dependencies since the source tarball includes some processed
files that are not in the Git repository.
Other useful commands:
zig build testfor running unit tests.zig build test -Dtest-filter=<filter>for running a specific subset of those unit testszig build run -Dconformance=<name>runs a conformance test case from theconformancedirectory. Thenameis the name of the file. This runs in the current running terminal emulator so if you want to check the behavior of this project, you must run this command in Ghostty.
Extra Dependencies
Building Ghostty from a Git checkout on Linux requires some additional dependencies:
blueprint-compiler
macOS users don't require any additional dependencies.
Note
This only applies to building from a Git checkout. This section does not apply if you're building from a released source tarball. For source tarballs, see the website.
Xcode Version and SDKs
Building the Ghostty macOS app requires that Xcode, the macOS SDK, and the iOS SDK are all installed.
A common issue is that the incorrect version of Xcode is either
installed or selected. Use the xcode-select command to
ensure that the correct version of Xcode is selected:
sudo xcode-select --switch /Applications/Xcode-beta.app
Important
Main branch development of Ghostty is preparing for the next major macOS release, Tahoe (macOS 26). Therefore, the main branch requires Xcode 26 and the macOS 26 SDK.
You do not need to be running on macOS 26 to build Ghostty, you can still use Xcode 26 beta on macOS 15 stable.
Linting
Prettier
Ghostty's docs and resources (not including Zig code) are linted using Prettier with out-of-the-box settings. A Prettier CI check will fail builds with improper formatting. Therefore, if you are modifying anything Prettier will lint, you may want to install it locally and run this from the repo root before you commit:
prettier --write .
Make sure your Prettier version matches the version of Prettier in devShell.nix.
Nix users can use the following command to format with Prettier:
nix develop -c prettier --write .
Alejandra
Nix modules are formatted with Alejandra. An Alejandra CI check will fail builds with improper formatting.
Nix users can use the following command to format with Alejandra:
nix develop -c alejandra .
Non-Nix users should install Alejandra and use the following command to format with Alejandra:
alejandra .
Make sure your Alejandra version matches the version of Alejandra in devShell.nix.
Updating the Zig Cache Fixed-Output Derivation Hash
The Nix package depends on a fixed-output derivation that manages the Zig package cache. This allows the package to be built in the Nix sandbox.
Occasionally (usually when build.zig.zon is updated), the hash that
identifies the cache will need to be updated. There are jobs that monitor the
hash in CI, and builds will fail if it drifts.
To update it, you can run the following in the repository root:
./nix/build-support/check-zig-cache-hash.sh --update
This will write out the nix/zigCacheHash.nix file with the updated hash
that can then be committed and pushed to fix the builds.