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

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...

also.. now I want to attempt to write a Ghostty frontend as a Godot extension

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.

>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?

Speaking of ghostly, I seem to have issues with using Alt shortcuts in helix running in ghostty on Mac OS. I haven’t taken time to investigate more than activating Alt via the option key in Mac.

Fun fact. In Ghostty and (some) other GTK apps, if your mouse leaves the window, the first scroll click after re-entering the window is ignored. This is due to an ancient bug first identified in 2015.

https://bugzilla.gnome.org/show_bug.cgi?id=750994

There are no plans for a fix. The maintainer recommends waiting for Wayland.

> also verifying with Valgrind every step of the way

This is...both extremely obvious, and also not something that I've ever done before, thought of doing, or seen anyone else do.

Every single instance of Valgrind usage I've encountered or initiated has been triggered by a specific bug or performance regression.

Proactive use of the Valgrind suite (Memcheck and Helgrind at least) as part of the development process would probably result in massively better stability of most tools - and would also make it far easier to find bugs (as you could find them when they were introduced rather than hundreds of commits later).

Biggest issue I have with Ghostty is that on the mac with Nano.. you can't copy and paste multiple lines into the editor. It's something about how the terminal handles "bracketed pasting".. but yet this isn't an issue with iterm2 and term.

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.

I've been using Ghostty, and other GPU-based apps like Alacritty / WezTerm / Zed, because they're ofc better/faster...

Ironically they've all made my DX worse, by highlighting how terrible the nvidia drivers actually worked on both my old Regolith i3wm/compositor-less or new sway/wayland setup.

Like it's ridiculously terrible.

I've tried every magical env flag that Claude can think of, and 4 of the various 550/560/575/580 driver versions--they all suck at screensharing, or resume from sleep, or just out-right buginess/crashes/segfaults in the nvidia drivers.

It must have always been this bad, but I just didn't notice, b/c I never actually used my GPU? lol

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.

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.)

> This has already led to more easily introducing GUI features like a new GTK titlebar tabs option

Yes! This is huge, I previously gave up on Ghostty because the title bar wasted so much space on my laptop screen: https://bsky.app/profile/reillywood.bsky.social/post/3lebapf...

I found the PR in case anyone else is curious what the new functionality looks like: https://github.com/ghostty-org/ghostty/pull/8166

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.

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.

Wouldn't Vala be a better option instead of Zig?

I wouldn’t call GTK the “native” framework on Linux/Wayland or Linux/X11.

Native would be talking to the compositor directly.

GTK provides a cross-platform layer of abstractions over the compositor. That’s the opposite of native.

There’s countless bugs in the Linux port for applications (eg: Firefox) which can’t be fixed because of a he abstractions done by GTK.

I'll take QObject over GObject any day of the week.

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!

Honestly i'd write the UI parts in vala if i'd want to make a gnome native app

> This is now my 5th time writing the GUI part of Ghostty from scratch: [...] once on macOS with SwiftUI, then on macOS with AppKit plus SwiftUI [...]

Ha, that's a nice way of wording that. I'd take it a step or two further. :)

“Ghostty is cross platform…” but not on windows :D

“App XYZ is mobile ready…” but not on Android.

Same vibe