9 ms·

We rewrote the Ghostty GTK application

428 points by tosh 1y ago

corsica 1y ago
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 1y ago
  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 1y ago
    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 1y ago
    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 1y ago
      And someone already did: https://github.com/gabydd/wraith https://github.com/gabydd/wraith (Wayland-only frontend, extremely lightweight). Super cool.
- do_not_redeem 1y ago
  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.)
  - akulbe 1y ago
    What about Qt? Would that have been a better experience? Or would you experience different issues?
    - TUSF 1y ago
      Qt has no official C bindings. This makes it difficult for a new language to write Qt bindings, unlike for GTK.
- mitchellh 1y ago
  > 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.
  - LambdaComplex 1y ago
    I know I'm about to show my ignorance regarding GUI programming here, but: would SDL2 be a suitable choice? Or would that be too low-level? Or just...the wrong sort of library?
    - troad 1y ago
      SDL2 wouldn't be appropriate for what they're trying to do. SDL2 is more of a drawing and graphics library. You tell it to put a triangle here, it puts a triangle there. But it has no idea what a button should look like - how it should behave, how it should be animated - on Mac, on Windows, on KDE, on Gnome, etc. You could try to painstakingly recreate this look and feel for each platform, but it's a lot of effort, you probably won't get it quite right, you'll make oversights on accessibility and internationalisation, and your hard work will instantly look dated once the platform evolves. To make native GUIs, you need to talk to the libraries that draw platform-native components, like buttons, for you. But of course each platform works totally differently, and the whole affair is honestly kind of a mess, which is why truly native cross-platform applications tend to be fairly rare in practice. Maintaining five different GUI code bases for all sorts of fringe platforms is not, in most cases, a good use of time. For most apps, either you stick to native and cut less significant platforms, or you abandon native altogether and just use a cross-platform wrapper like Electron.
- Lerc 1y ago
  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 1y ago
  In addition to what others have said (positively), ‘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.
- sevg 1y ago
  > Kovid was able to quickly implement Is this new account actually Kovid? Context: “aumerle” had posted only about Kitty for years as though impartial. And talked about Kovid as if they were a different person. Turns out “aumerle” is Kovid and got banned. He was trash-talking ghostty and advertising Kitty in every ghostty thread. (He does the same using “aumerlex” on reddit, but nobody has called him out on there yet.) I’m suspicious here because Kovid spent hours trying to force me to admit that he writes code faster than Mitchell XD https://news.ycombinator.com/item?id=42567224 https://news.ycombinator.com/item?id=42567224 (you’ll need “showdead” enabled, all of Kovid’s comments got flagged to death).
- iammrpayments 1y ago
  My font doesn’t look as nice on Kitty as it does on Ghostty. The only place that looks better than ghostty is neovide, but they don’t support tabs yet, and because it is more resource intensive, it drains the battery faster.
crawshaw 1y ago
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.
- eviks 1y ago
  Giving in a bad system is more pragmatic rather than good
  - hnlmorg 1y ago
    The two terms aren’t mutually exclusive
    - eviks 1y ago
      Only in a dictionary. In a sentence that has the context of a poorly designed system, they are because you explicitly have to do worse programming to meet the system at a worse point
      - hnlmorg 1y ago
        “Good” and “bad” are subjective. Being pragmatic about the design of an ecosystem and working with it, could be seen as good programming vs the alternative of fighting that ecosystem and thus creating entirely new classes of bugs. And this was what the GP was responding to. They were was that the pragmatism of working with that ecosystem showed good judgement.
  - flohofwoe 1y ago
    Careful what you wish for. These days one has to be thankful if a badly designed old system isn't replaced with a new system that's even worse despite the best intentions ;)
Lerc 1y ago
>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 1y ago
  > 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 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 https://ghostty.org/docs/about#libghostty For example Wraith is a Wayland-native Ghostty frontend (no GTK): https://github.com/gabydd/wraith https://github.com/gabydd/wraith Awesome.
  - LambdaComplex 1y ago
8f2ab37a-ed6c 1y ago
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 1y ago
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 1y ago
  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 1y ago
    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?
    - wofo 1y ago
      Having worked on a few Rust projects that interface with C libraries, I think your last question is a good summary: once you introduce a C API boundary it's back to tools like Valgrind. Maybe you could even say Zig is at an advantage there, because tools like Valgrind are considered part of the game, whereas in Rust they are way less commonly used (pure-Rust codebases don't need anything of the sort, unless you are using `unsafe`).
    - sbt567 1y ago
      I vaguely remember that there is a new language that promises "Safety across FFI boundary", but can't recall the name
    - NobodyNada 1y ago
      In general: whenever you call into C, you get all the safety of C, because C code can trivially have memory corruption bugs that corrupt memory "belonging" to Rust as well, inducing undefined behavior across your whole program [0]. In addition, it's often considered permissible for C APIs to exhibit undefined behavior if their API contracts are violated. This means that a bug in Rust code that calls into a C API incorrectly can (indirectly) cause undefined behavior. For this reason, all FFI calls are marked unsafe in Rust. The typical approach to using C libraries from Rust is to create a "safe wrapper" around the unsafe FFI calls that uses Rust's type system and lifetimes to enforce the safety invariants. Of course it's possible to mess up this wrapper and have accidental undefined behavior, but you're much less likely to do so through a safe wrapper than if you use the unsafe FFI calls directly (or use C or Zig) for a couple reasons: - Writing the safe wrapper forces you to sit down and think about safety invariants instead of glossing over it. - Once you're done, the compiler will check the safety invariants for you every time you use the API -- no chance of making a mistake or forgetting to read a comment. [0]: This could be avoided/mitigated with some kind of lightweight in-process sandboxing (e.g. Intel MPK + seccomp) to prevent C libraries from accessing memory that they don't own or performing syscalls they shouldn't. There's some academic research on this (and I experimented with it myself for a masters thesis project), but it generally requires some (minimal) performance overhead and code changes at language boundaries.
WD-42 1y ago
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 1y ago
  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.
  - WD-42 1y ago
    Looking forward to it!
rvrb 1y ago
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 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/SignalNode.zig 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
- aidenn0 1y ago
  Hopefully it's improved, but the last time I wrote a GTK binding for a language, it was miserable. 98% of it was sane, but the remaining 2% had things like "whether or not this function takes a reference to this object depends on the other parameters passed" which made liveness analysis "interesting."
  - DanielHB 1y ago
    This is what people mean when they say "make invalid states unrepresentable", languages with union types can easily avoid this problem.
    - biorach 1y ago
      It doesn't sound like they are talking about invalid states, more like they are taking about the kind of thing that in Rust would be represented by `Option<Box<dyn SomeTrait>>` or suchlike. Maybe your point is that in Rust much less ceremony is necessary to avoid hitting a null pointer when doing this. But still, in either language it's easy to end up with hard to follow logic when doing this.
jwar767 1y ago
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 1y ago
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.
LeSaucy 1y ago
I'll take QObject over GObject any day of the week.
ripley12 1y ago
> 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/3lebapf3dlk22 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 https://github.com/ghostty-org/ghostty/pull/8166
- mixmastamyk 1y ago
  If it’s not maximized, the space isn’t wasted. The title in the response image looks incredibly crowded. May be ok if several buttons could be removed from the titlebar.
  - eviks 1y ago
    It's literally wasted because it's used for nothing useful. Also, you can have other apps that now can take up less area.
    - mixmastamyk 1y ago
      Titlebars are quite useful, I use them frequently to move, raise, lower, and maximize windows.
      - eviks 1y ago
        Oh sure, but some people use more ergonomic ways to perform those actions, so to them the title bars would be a waste even if not maximized
        mixmastamyk 1y ago
        Nothing more “ergonomic” than a titlebar. Discoverable, standard, usable.
      - 1y ago
metaltyphoon 1y ago
“Ghostty is cross platform…” but not on windows :D “App XYZ is mobile ready…” but not on Android. Same vibe
- WhereIsTheTruth 1y ago
  Windows is just a web browser, yes i'm serious
  - bitwize 1y ago
    Windows is BonziBuddy with OS functionality attached.
    - JoyceBabu 1y ago
      BonziBuddy. I remember using it long back, was fun back then. Later heard that they injected malicious code into the software.
- AndyKelley 1y ago
  Windows is becoming less and less of a platform every year
  - metaltyphoon 1y ago
    Not saying you are wrong, but this is akin to “this is the year of the Linux Desktop”. You probably don’t have this telemetry but have you thought about how having window support helps Zig adoption? Anecdotal, at day job, we started to use Zig build system to target Windows because that’s where the customers are.
    - AndyKelley 1y ago
      Yeah. I just wish Microsoft were better stewards of the OS.
      - 1y ago
stephen 1y ago
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
- aidenn0 1y ago
  I had a similar experience with Wayland. If I turned compositing effects of in X11, everything worked fine on my two machines (one with a 1050Ti, the other with an AMD card old enough to need the "radeon" driver). Wayland would lag, or crash or just show garbled output.
throw10920 1y ago
> 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).
- account42 1y ago
  I've used Valgrind (mainly memcheck) as a proactive tool or at least as a tool to fish for easy to fix issues before spending too much time debugging specific reports. Main issue is the huge performance overhead that make interactive use under it less than fun - but IMO running your testsuite under it from time to time at least is a no brainer.
- ur-whale 1y ago
  > Proactive use of the Valgrind suite (Memcheck and Helgrind at least) as part of the development process Yeah, except that it's: slow and expensive and therefore can't be a part of the "short cycle" (edit code, compile, test, iterate) only the "long cycle" (nightly build, test suite). Also valgrind is not exactly designed to directly integrate in a test suite and that requires work.
- any1 1y ago
  I've used valgrind proactively as long as I've been programming in C and C++. The errors that are caught by valgrind (and asan) will very often not cause immediate crashes or any kind of obvious bugs. Instead, they cause intermittent bugs that are very hard to catch otherwise. They may even be security vulnerabilities. Another good reason for using it proactively is that small memory leaks tend to sneak in over time. They might not cause any issues and most of them aren't accumulative. However, having all those leaks in there makes it much more difficult to find big leaks when they happen because you have to sift through all the insignificant ones before you can fix the one that's causing problems.
monksy 1y ago
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.
- ha1zum 1y ago
  This could be a valid bug that you can report
- dewey 1y ago
  I've used Ghostty as my default terminal since I set up my new computer a couple of months ago. The only issue I have is the missing search which I often reach for to look through output that I didn't pipe anywhere. Bit it's also the most mentioned issue: https://github.com/ghostty-org/ghostty/issues/189 https://github.com/ghostty-org/ghostty/issues/189
  - scosman 1y ago
    Agreed. This is the only thing stopping it from being the undisputed best terminal for me. I’ve referred 2 people to it in the last few months, both like it but didn’t adopt it because of this.
- qweiopqweiop 1y ago
  No command f is the killer for me
- Sammi 1y ago
  I can't even open nano in ghostty when I've ssh'd to my ubuntu box: $ nano Error opening terminal: xterm-ghostty. Works fine in macos terminal and built in vs code terminal.
  - biorach 1y ago
    Might be $TERM needs to be set or you need to add ghostty to terminfo
rweichler 1y ago
> 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. :)
carodgers 1y ago
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 https://bugzilla.gnome.org/show_bug.cgi?id=750994 There are no plans for a fix. The maintainer recommends waiting for Wayland.
- pilif 1y ago
  Reading the report you reference and other issues linked there, I would say that multiple attempts were made to fix it, all of which unfortunately required some heuristics and all of which have broken something else that was deemed worse. It seems to boil down to an issue in the underlying X11 machinery and it would need to be fixed there first to build a basis on which proper fixes can be implemented. Given that X11 is in maintenance mode (and as its fans keep saying: It works perfectly fine and doesn't need any more work done on it), it's not likely that's happening. So, yes, given that information (and I just arrived at that bug report through your post), I would indeed say that waiting for Wayland is the only option they have. All other attempts ended up causing worse issues.
  - account42 1y ago
    Other toolkits don't seem to have this issue on X11.
    - pilif 1y ago
      those toolkits do not support smooth scrolling. The issue comes from XInput2 (https://www.x.org/releases/X11R7.7/doc/inputproto/XI2proto.txt https://www.x.org/releases/X11R7.7/doc/inputproto/XI2proto.t...) So I guess the "fix" would be to have two completely separate input handlers on X11, one of which supporting smooth scrolling and multitouch, the other not and then offering users a toggle in the style of [ ] do not ignore the first scroll input after focus loss, but disable smooth scrolling and multitouch Plus handling all the potential issues by having two separate input handlers. That's asking a bit much for this particular issue und greatly smells like a case of XKCD 1172
Cloudef 1y ago
Honestly i'd write the UI parts in vala if i'd want to make a gnome native app
- zerr 1y ago
  For non-UI parts as well, it's a nice language. I wish Windows support was first class though.
WhyNotHugo 1y ago
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.
- lumpa 1y ago
  Linux people get really worked up when I say "platform-native". There is no such thing on Linux, but reasonable people agree that something like a GTK app (or Qt) feels "native" on *most desktops* over other applications. https://mitchellh.com/writing/ghostty-gtk-rewrite#user-content-fn-1 https://mitchellh.com/writing/ghostty-gtk-rewrite#user-conte...
- MadcapJake 1y ago
  "native" here means using the same toolkit as the desktop environment.
- tuna74 1y ago
  There is no "native" compositor for Linux either. The most used one is the one that Android uses.
zerr 1y ago
Wouldn't Vala be a better option instead of Zig?
jiehong 1y ago
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.
- RGBCube 1y ago
  You need to enable the option-key-as-alt config option (I recommend only doing it for left option) as alt and option aren't actually the same thing. The name of the config key may be different but it exists

428 points by tosh 1y ago

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 1y ago
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 1y ago
  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 1y ago
  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 1y ago
    And someone already did: https://github.com/gabydd/wraith https://github.com/gabydd/wraith (Wayland-only frontend, extremely lightweight). Super cool.
do_not_redeem 1y ago
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.)
- akulbe 1y ago
  What about Qt? Would that have been a better experience? Or would you experience different issues?
  - TUSF 1y ago
    Qt has no official C bindings. This makes it difficult for a new language to write Qt bindings, unlike for GTK.
mitchellh 1y ago
> 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.
- LambdaComplex 1y ago
  I know I'm about to show my ignorance regarding GUI programming here, but: would SDL2 be a suitable choice? Or would that be too low-level? Or just...the wrong sort of library?
  - troad 1y ago
    SDL2 wouldn't be appropriate for what they're trying to do. SDL2 is more of a drawing and graphics library. You tell it to put a triangle here, it puts a triangle there. But it has no idea what a button should look like - how it should behave, how it should be animated - on Mac, on Windows, on KDE, on Gnome, etc. You could try to painstakingly recreate this look and feel for each platform, but it's a lot of effort, you probably won't get it quite right, you'll make oversights on accessibility and internationalisation, and your hard work will instantly look dated once the platform evolves. To make native GUIs, you need to talk to the libraries that draw platform-native components, like buttons, for you. But of course each platform works totally differently, and the whole affair is honestly kind of a mess, which is why truly native cross-platform applications tend to be fairly rare in practice. Maintaining five different GUI code bases for all sorts of fringe platforms is not, in most cases, a good use of time. For most apps, either you stick to native and cut less significant platforms, or you abandon native altogether and just use a cross-platform wrapper like Electron.
Lerc 1y ago
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 1y ago
In addition to what others have said (positively), ‘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.
sevg 1y ago
> Kovid was able to quickly implement Is this new account actually Kovid? Context: “aumerle” had posted only about Kitty for years as though impartial. And talked about Kovid as if they were a different person. Turns out “aumerle” is Kovid and got banned. He was trash-talking ghostty and advertising Kitty in every ghostty thread. (He does the same using “aumerlex” on reddit, but nobody has called him out on there yet.) I’m suspicious here because Kovid spent hours trying to force me to admit that he writes code faster than Mitchell XD https://news.ycombinator.com/item?id=42567224 https://news.ycombinator.com/item?id=42567224 (you’ll need “showdead” enabled, all of Kovid’s comments got flagged to death).
iammrpayments 1y ago
My font doesn’t look as nice on Kitty as it does on Ghostty. The only place that looks better than ghostty is neovide, but they don’t support tabs yet, and because it is more resource intensive, it drains the battery faster.

crawshaw 1y ago

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.

eviks 1y ago
Giving in a bad system is more pragmatic rather than good
- hnlmorg 1y ago
  The two terms aren’t mutually exclusive
  - eviks 1y ago
    Only in a dictionary. In a sentence that has the context of a poorly designed system, they are because you explicitly have to do worse programming to meet the system at a worse point
    - hnlmorg 1y ago
      “Good” and “bad” are subjective. Being pragmatic about the design of an ecosystem and working with it, could be seen as good programming vs the alternative of fighting that ecosystem and thus creating entirely new classes of bugs. And this was what the GP was responding to. They were was that the pragmatism of working with that ecosystem showed good judgement.
- flohofwoe 1y ago
  Careful what you wish for. These days one has to be thankful if a badly designed old system isn't replaced with a new system that's even worse despite the best intentions ;)

Lerc 1y ago

>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 1y ago
> 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 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 https://ghostty.org/docs/about#libghostty For example Wraith is a Wayland-native Ghostty frontend (no GTK): https://github.com/gabydd/wraith https://github.com/gabydd/wraith Awesome.
- LambdaComplex 1y ago

8f2ab37a-ed6c 1y ago

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 1y ago

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 1y ago
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 1y ago
  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?
  - wofo 1y ago
    Having worked on a few Rust projects that interface with C libraries, I think your last question is a good summary: once you introduce a C API boundary it's back to tools like Valgrind. Maybe you could even say Zig is at an advantage there, because tools like Valgrind are considered part of the game, whereas in Rust they are way less commonly used (pure-Rust codebases don't need anything of the sort, unless you are using `unsafe`).
  - sbt567 1y ago
    I vaguely remember that there is a new language that promises "Safety across FFI boundary", but can't recall the name
  - NobodyNada 1y ago
    In general: whenever you call into C, you get all the safety of C, because C code can trivially have memory corruption bugs that corrupt memory "belonging" to Rust as well, inducing undefined behavior across your whole program [0]. In addition, it's often considered permissible for C APIs to exhibit undefined behavior if their API contracts are violated. This means that a bug in Rust code that calls into a C API incorrectly can (indirectly) cause undefined behavior. For this reason, all FFI calls are marked unsafe in Rust. The typical approach to using C libraries from Rust is to create a "safe wrapper" around the unsafe FFI calls that uses Rust's type system and lifetimes to enforce the safety invariants. Of course it's possible to mess up this wrapper and have accidental undefined behavior, but you're much less likely to do so through a safe wrapper than if you use the unsafe FFI calls directly (or use C or Zig) for a couple reasons: - Writing the safe wrapper forces you to sit down and think about safety invariants instead of glossing over it. - Once you're done, the compiler will check the safety invariants for you every time you use the API -- no chance of making a mistake or forgetting to read a comment. [0]: This could be avoided/mitigated with some kind of lightweight in-process sandboxing (e.g. Intel MPK + seccomp) to prevent C libraries from accessing memory that they don't own or performing syscalls they shouldn't. There's some academic research on this (and I experimented with it myself for a masters thesis project), but it generally requires some (minimal) performance overhead and code changes at language boundaries.

WD-42 1y ago

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 1y ago
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.
- WD-42 1y ago
  Looking forward to it!

rvrb 1y ago

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 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/SignalNode.zig 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

aidenn0 1y ago
Hopefully it's improved, but the last time I wrote a GTK binding for a language, it was miserable. 98% of it was sane, but the remaining 2% had things like "whether or not this function takes a reference to this object depends on the other parameters passed" which made liveness analysis "interesting."
- DanielHB 1y ago
  This is what people mean when they say "make invalid states unrepresentable", languages with union types can easily avoid this problem.
  - biorach 1y ago
    It doesn't sound like they are talking about invalid states, more like they are taking about the kind of thing that in Rust would be represented by `Option<Box<dyn SomeTrait>>` or suchlike. Maybe your point is that in Rust much less ceremony is necessary to avoid hitting a null pointer when doing this. But still, in either language it's easy to end up with hard to follow logic when doing this.

jwar767 1y ago

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 1y ago

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.

LeSaucy 1y ago

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

ripley12 1y ago

> 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/3lebapf3dlk22 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 https://github.com/ghostty-org/ghostty/pull/8166

mixmastamyk 1y ago
If it’s not maximized, the space isn’t wasted. The title in the response image looks incredibly crowded. May be ok if several buttons could be removed from the titlebar.
- eviks 1y ago
  It's literally wasted because it's used for nothing useful. Also, you can have other apps that now can take up less area.
  - mixmastamyk 1y ago
    Titlebars are quite useful, I use them frequently to move, raise, lower, and maximize windows.
    - eviks 1y ago
      Oh sure, but some people use more ergonomic ways to perform those actions, so to them the title bars would be a waste even if not maximized
      - mixmastamyk 1y ago
        Nothing more “ergonomic” than a titlebar. Discoverable, standard, usable.
    - 1y ago

metaltyphoon 1y ago

“Ghostty is cross platform…” but not on windows :D “App XYZ is mobile ready…” but not on Android. Same vibe

WhereIsTheTruth 1y ago
Windows is just a web browser, yes i'm serious
- bitwize 1y ago
  Windows is BonziBuddy with OS functionality attached.
  - JoyceBabu 1y ago
    BonziBuddy. I remember using it long back, was fun back then. Later heard that they injected malicious code into the software.
AndyKelley 1y ago
Windows is becoming less and less of a platform every year
- metaltyphoon 1y ago
  Not saying you are wrong, but this is akin to “this is the year of the Linux Desktop”. You probably don’t have this telemetry but have you thought about how having window support helps Zig adoption? Anecdotal, at day job, we started to use Zig build system to target Windows because that’s where the customers are.
  - AndyKelley 1y ago
    Yeah. I just wish Microsoft were better stewards of the OS.
    - 1y ago

stephen 1y ago

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

aidenn0 1y ago
I had a similar experience with Wayland. If I turned compositing effects of in X11, everything worked fine on my two machines (one with a 1050Ti, the other with an AMD card old enough to need the "radeon" driver). Wayland would lag, or crash or just show garbled output.

throw10920 1y ago

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

account42 1y ago
I've used Valgrind (mainly memcheck) as a proactive tool or at least as a tool to fish for easy to fix issues before spending too much time debugging specific reports. Main issue is the huge performance overhead that make interactive use under it less than fun - but IMO running your testsuite under it from time to time at least is a no brainer.
ur-whale 1y ago
> Proactive use of the Valgrind suite (Memcheck and Helgrind at least) as part of the development process Yeah, except that it's: slow and expensive and therefore can't be a part of the "short cycle" (edit code, compile, test, iterate) only the "long cycle" (nightly build, test suite). Also valgrind is not exactly designed to directly integrate in a test suite and that requires work.
any1 1y ago
I've used valgrind proactively as long as I've been programming in C and C++. The errors that are caught by valgrind (and asan) will very often not cause immediate crashes or any kind of obvious bugs. Instead, they cause intermittent bugs that are very hard to catch otherwise. They may even be security vulnerabilities. Another good reason for using it proactively is that small memory leaks tend to sneak in over time. They might not cause any issues and most of them aren't accumulative. However, having all those leaks in there makes it much more difficult to find big leaks when they happen because you have to sift through all the insignificant ones before you can fix the one that's causing problems.

monksy 1y ago

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.

ha1zum 1y ago
This could be a valid bug that you can report
dewey 1y ago
I've used Ghostty as my default terminal since I set up my new computer a couple of months ago. The only issue I have is the missing search which I often reach for to look through output that I didn't pipe anywhere. Bit it's also the most mentioned issue: https://github.com/ghostty-org/ghostty/issues/189 https://github.com/ghostty-org/ghostty/issues/189
- scosman 1y ago
  Agreed. This is the only thing stopping it from being the undisputed best terminal for me. I’ve referred 2 people to it in the last few months, both like it but didn’t adopt it because of this.
qweiopqweiop 1y ago
No command f is the killer for me
Sammi 1y ago
I can't even open nano in ghostty when I've ssh'd to my ubuntu box: $ nano Error opening terminal: xterm-ghostty. Works fine in macos terminal and built in vs code terminal.
- biorach 1y ago
  Might be $TERM needs to be set or you need to add ghostty to terminfo

rweichler 1y ago

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

carodgers 1y ago

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 https://bugzilla.gnome.org/show_bug.cgi?id=750994 There are no plans for a fix. The maintainer recommends waiting for Wayland.

pilif 1y ago
Reading the report you reference and other issues linked there, I would say that multiple attempts were made to fix it, all of which unfortunately required some heuristics and all of which have broken something else that was deemed worse. It seems to boil down to an issue in the underlying X11 machinery and it would need to be fixed there first to build a basis on which proper fixes can be implemented. Given that X11 is in maintenance mode (and as its fans keep saying: It works perfectly fine and doesn't need any more work done on it), it's not likely that's happening. So, yes, given that information (and I just arrived at that bug report through your post), I would indeed say that waiting for Wayland is the only option they have. All other attempts ended up causing worse issues.
- account42 1y ago
  Other toolkits don't seem to have this issue on X11.
  - pilif 1y ago
    those toolkits do not support smooth scrolling. The issue comes from XInput2 (https://www.x.org/releases/X11R7.7/doc/inputproto/XI2proto.txt https://www.x.org/releases/X11R7.7/doc/inputproto/XI2proto.t...) So I guess the "fix" would be to have two completely separate input handlers on X11, one of which supporting smooth scrolling and multitouch, the other not and then offering users a toggle in the style of [ ] do not ignore the first scroll input after focus loss, but disable smooth scrolling and multitouch Plus handling all the potential issues by having two separate input handlers. That's asking a bit much for this particular issue und greatly smells like a case of XKCD 1172

Cloudef 1y ago

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

zerr 1y ago
For non-UI parts as well, it's a nice language. I wish Windows support was first class though.

WhyNotHugo 1y ago

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.

lumpa 1y ago
Linux people get really worked up when I say "platform-native". There is no such thing on Linux, but reasonable people agree that something like a GTK app (or Qt) feels "native" on *most desktops* over other applications. https://mitchellh.com/writing/ghostty-gtk-rewrite#user-content-fn-1 https://mitchellh.com/writing/ghostty-gtk-rewrite#user-conte...
MadcapJake 1y ago
"native" here means using the same toolkit as the desktop environment.
tuna74 1y ago
There is no "native" compositor for Linux either. The most used one is the one that Android uses.

zerr 1y ago

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

jiehong 1y ago

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.

RGBCube 1y ago
You need to enable the option-key-as-alt config option (I recommend only doing it for left option) as alt and option aren't actually the same thing. The name of the config key may be different but it exists