[HN Gopher] We rewrote the Ghostty GTK application
___________________________________________________________________
We rewrote the Ghostty GTK application
Author : tosh
Score : 96 points
Date : 2025-08-14 21:19 UTC (1 hours ago)
(HTM) web link (mitchellh.com)
(TXT) w3m dump (mitchellh.com)
| corsica wrote:
| I don't get the hype around this application. The only UI Ghostty
| has is tabs and the context menu, is it really worth the
| integration pain and now this rewrite?
|
| Maybe they're planning for more, like those GUI configuration
| dialogs that iterm2 has?
|
| Kitty uses OpenGL for everything and draws its own tabs, they're
| fully customizable and can be made to look however you want. By
| not wasting time on integrating with massive frameworks for
| _drawing tabs_ , Kovid was able to quickly implement really
| useful things that Ghostty is sorely missing, like wrapping the
| output of the last command in a pager (run 'ps -auxf' and press
| Ctrl+Shift+G -- this thing so useful it's hard to go without it
| now. It also works for remote shells across SSH sessions.)
| hyperbolablabla wrote:
| Agreed, seems like a lot of unnecessary girating just to
| implement something that would've been much simpler + cross-
| platform with a custom UI toolkit and something like opengl.
| Tabs are like UI 101
| ChocolateGod wrote:
| Easier integration with the desktops accessibility and input
| stack? When using GTK, you would probably also get out the
| box better performance/power on Wayland since it can take
| care of partial surface updates etc for you.
| WD-42 wrote:
| Luckily the UI and the core (libghostty) are separate so you
| can girate out your own UI 101 version without GTK if you'd
| like.
| mitchellh wrote:
| And someone already did: https://github.com/gabydd/wraith
| (Wayland-only frontend, extremely lightweight). Super cool.
| do_not_redeem wrote:
| Well... a terminal is a GUI app, so they had to choose _some_
| GUI framework. On Linux GTK is as good a choice as any. (Yes I
| know you can skip the framework and talk to X11 /Wayland
| directly, like xterm/foot do, but that's a pain all of its
| own.)
| mitchellh wrote:
| > The only UI Ghostty has is tabs and the context menu
|
| - Tabs
|
| - Splits
|
| - "this process has exited" banner
|
| - Close confirmation dialogs
|
| - Change title dialog
|
| - Unsafe paste detection dialogs
|
| - Context menus
|
| - Animated bells (opt in)
|
| - "Quake-style" dropdown terminals (cross platform but
| different mechanisms)
|
| - Progress bars (ConEmu OSC 9;4)
|
| - macOS: Apple Shortcuts Integration
|
| - macOS: Spotlight Integration
|
| Probably more I'm not thinking of. It's unfair to say it's just
| tabs. Could we have done this without a GUI toolkit? Of course!
| But the whole mission statement of this project was always to
| use platform-native (for various definitions) toolkits so that
| it _feels_ native.
|
| That's not for everyone, and that's the great thing about the
| wonderful vibrant terminal ecosystem we have.
|
| > is it really worth the integration pain and now this rewrite?
|
| There's definitely a lot more on the way.
|
| The first goal and primary focus of the project was to build a
| stable, feature rich (terminal sequences) terminal emulator.
| We're basically there. Next up, we're expanding GUI
| functionality significantly, including having more escape
| sequences result in more native GUI elements. But also
| traditional things like preferences GUIs, yes.
|
| We're also integrating a lot more deeply with native features
| provided by each platform (somewhat related to the GUI toolkit
| choice), such as automatic iCloud syncing of your configuration
| on macOS. Now that the terminal is stable, we can start to
| really lean in to application features.
|
| This isn't for everyone. Some people like Kitty's textual tabs.
| That's fine! It's a tradeoff. That's the beauty of choice. :)
| Kitty is a great terminal, if you prefer it, please use it. But
| it has completely different tradeoffs than Ghostty.
| Lerc wrote:
| I went on a big meandering hunt for a terminal application that
| did what I wanted. I have tried many and while nothing
| perfectly met my needs, Ghostty is the one I am using now.
|
| That counts for something.
|
| Perhaps it is just it lacks an obvious reason to move away from
| it. Usually, the thing that made me try another terminal was
| because of something I couldn't do. It wasn't a matter of
| listing all the pros and cons and going with the best one. It
| has just found a home with me because it hasn't outstayed its
| welcome.
| alberth wrote:
| In addition to what others have said, libghostty is also a game
| changer.
|
| It's like the "WebKit" for terminal, as I understand it.
|
| Anyone could drop-in libghostty, and immediately have a fully
| functional terminal.
| crawshaw wrote:
| Nice example of how good programming is often about meeting
| systems where they are: Whatever your feelings
| are about OOP and memory management, the reality is that if you
| choose GTK, you're forced into interfacing in some way with the
| GObject type system. You can't avoid it. Well you can
| avoid it and we did avoid it. And it leads to a mess trying to
| tie the lifetimes of your non-reference-counted objects to the
| reference counted ones. There was an entire class of bug that
| kept popping up in the Ghostty GTK application that could
| basically be summed up as: the Zig memory or the GTK memory has
| been freed, but not both.
| Lerc wrote:
| > _Whatever your feelings are about OOP and memory management,
| the reality is that if you choose GTK, you 're forced into
| interfacing in some way with the GObject type system. You can't
| avoid it._
|
| In the past this has also been my assessment of GTK. It lead me
| to decide to take the other path, to never directly use GTK. I
| appreciate the value in having a unified user interface between
| applications, but I have always thought the features that GTK
| provides were not worth the penalties paid. I have worked around
| the edges of GTK in open source apps that are GTK based. That
| lead me to think that GTK and the GObject system is opinionated
| in a way that are not terribly compatible with my own opinions.
|
| I don't hate that GTK exists, It is my choice not to use it and I
| am fine with that. However I also have encountered people who
| seem to think it is not my choice not to use it. There are a
| million and one other GUI toolkits out there, of which GTK is one
| of the most polished. I can't shake the feeling that if GTK were
| less dominant, some of the resources that go to polishing GTK
| might have been spent polishing a different framework with a
| nicer underlying architecture.
|
| Of course what I consider nicer might not be what others consider
| nicer. Of those who use GTK, how many use it begrudgingly, and
| how many feel like it is the best tool for the job?
| mitchellh wrote:
| > That lead me to think that GTK and the GObject system is
| opinionated in a way that are not terribly compatible with my
| own opinions.
|
| This might be amusing for me to say but... I also feel this
| way. I disagree a lot with the Gnome ecosystem's point of view.
| Funny!
|
| Using GTK for Linux was a pragmatic choice. A goal of Ghostty
| is to be "platform-native" (defined here because there's no
| such thing on Linux: https://ghostty.org/docs/about#native).
| GTK is by various definitions the most popular, widespread GUI
| toolkit on Linux that makes your app fit into _most_
| ecosystems. So, GTK it is.
|
| I hope `libghostty` will give rise to other apprts (maintained
| by 3rd parties, it's hard enough for me to maintain macOS and
| GTK) so that you aren't forced into it. See
| https://ghostty.org/docs/about#libghostty For example Wraith is
| a Wayland-native Ghostty frontend (no GTK):
| https://github.com/gabydd/wraith Awesome.
| 8f2ab37a-ed6c wrote:
| Been a happy Ghostty user for a couple of months, it's my daily
| driver now as far as macOS terminals go. Thanks for all the hard
| work Mitchell & team.
| schmichael wrote:
| I'm curious if Rust would have prevented the memory correctness
| errors assuming it replaced Zig in this scenario. It sounds like
| the vast majority were due to Zig/C interactions which makes me
| believe Rust would have had the same issues, but as a Go
| developer I am only guessing. I'm curious if there is a language
| that provides more tools to ensure correctness even when you're
| interacting with a huge amount of C.
| WD-42 wrote:
| I think one of the main points of the article was about how
| shockingly few memory issues they have encountered. He talks
| about how great of a fit zig + valgrind is.
| schmichael wrote:
| Indeed, but I'm curious about the second class of memory
| correctness issue he mentions:
|
| > 2. All other memory issues revolved around C API
| boundaries.
|
| Is this something Rust, or any other language, has the
| ability to prevent any more than any other language? Or once
| you introduce a C API boundary is it back to tools like
| Valgrind?
| mitchellh wrote:
| Hi @schmichael ;) Rust would've prevented one. The rest Rust
| wouldn't have prevented since as you already noticed, it was in
| the boundary layer and semantics of a C API. It would've only
| been as safe as the Rust wrapper. One argument is that the
| richer, more proven ecosystem of wrapper libraries may have
| prevented it versus my DIY wrappers.
|
| The one Rust would've prevented was a simple undefined memory
| access: https://github.com/ghostty-org/ghostty/pull/7982 (At
| least, I'm pretty sure Rust would've caught this). In practice,
| it meant that we were copying garbage memory on the first
| rendered frame, but that memory wasn't used or sent anywhere so
| in practice it was mostly safe. Still, its not correct!
| schmichael wrote:
| Hey Mitchell! Leave it to me to bait the comments. :)
|
| Thanks for validating my assumption that once you introduce a
| big blob o' C all bets are off and you're back to Valgrind
| (or similar tooling).
|
| > One argument is that the richer, more proven ecosystem of
| wrapper libraries may have prevented it
|
| Yeah but where's the fun in that? ;)
| pornel wrote:
| Rust has safe and reliable GTK bindings. They used gir to
| auto-generate the error-prone parts of the FFI based on
| schemas and introspection: https://gtk-rs.org/gir/book/
|
| Rust's bindings fully embrace GTK's refcounting, so there's
| no mismatch in memory management.
| ericbarrett wrote:
| Do you mean gtk-rs (https://gtk-rs.org/)? I have done a bit
| of programming with it. I respect the work behind it, but
| it is a monumental PITA - truly a mismatch of philosophies
| and design - and I would a thousand times rather deal with
| C/C++ correctness demons than attempt it again, unless I
| had hard requirements for soundness. Even then, if you use
| gtk-rs you are pulling in 100+ crate dependencies and who
| knows what lurks in those?
| mitchellh wrote:
| We also use gir to auto-generate our bindings. But stuff
| like this is not represented in gir:
| https://github.com/ghostty-
| org/ghostty/commit/7548dcfe634cd9... It could EASILY be
| represented in a wrapper (e.g. with a Drop trait) but that
| implies a well-written wrapper, which is my argument. It's
| not inherent in the safety Rust gives you.
|
| EDIT:
|
| I looked it up because I was curious, and a Drop trait is
| exactly what they do: https://github.com/gtk-rs/gtk-rs-
| core/blob/b7559d3026ce06838... and as far as I can tell
| this is manually written, not automatically generated from
| gir.
|
| So the safety does rely on the human, not the machine.
| WD-42 wrote:
| Very nice writeup! I was actually just wondering what was going
| on with Ghostty, I've been daily driving it since initial release
| but I haven't noticed any updates since then (not that anything
| is particularly lacking, it's a great terminal!)
|
| Good to hear the Mitchell and the team are still hacking away at
| it! Thanks for the great software!
| mitchellh wrote:
| Hold onto your butts cause 1.2 is weeks away and the release
| notes if printed would cause a [larger than we already have]
| deforestation problem.
| rvrb wrote:
| I haven't worked with GTK, but what you are describing here
| sounds reminiscent of what we have been dealing with trying to
| build Godot bindings in Zig with a nice API. the project is in
| mid-flight, but Godot: - has tons of OOP
| concepts: classes, virtual methods, properties, signals, etc
| - a C API to work with all of those concepts, define your own
| objects, properties, and so on - manages the lifetimes of
| any engine objects (you can attach userdata to any of them)
| - a whole tree of reference counted objects
|
| it's a huge headache trying to figure out how to tie it into Zig
| idioms in a way that is an optimal API (specifically, dealing
| with lifetimes). we've come pretty far, but I am wondering if you
| have any additional insights or code snippets I should look at.
|
| working on this problem produced this library, which I am not
| proud of: https://github.com/gdzig/oopz
|
| here's a snippet that kind of demonstrates the state of the API
| at the moment:
| https://github.com/gdzig/gdzig/blob/master/example/src/Signa...
| jwar767 wrote:
| We had a similar experience to this at work. We wrote a google
| cloud service that interfaced with firestore using F# and found
| it painful because the firestore library is meant to be used with
| C#. It worked decently well but it was hard to write idiomatic F#
| without having a bunch of wrapping functions.
| Footnote7341 wrote:
| I managed to write a fairly large GTK application without the GTK
| type system encroaching on my code at all. It just meant hooking
| a bunch of lambdas in where they want you to be inheriting from
| and extending their own classes to allow all the parts to
| communicate together.
|
| In the end it wasn't that messy, but probably confusing for
| anyone used to writing dogmatic GTK applications.
___________________________________________________________________
(page generated 2025-08-14 23:00 UTC)