We rewrote the Ghostty GTK application(mitchellh.com)
mitchellh.com
We rewrote the Ghostty GTK application
https://mitchellh.com/writing/ghostty-gtk-rewrite
226 コメント
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."
This is what people mean when they say "make invalid states unrepresentable", languages with union types can easily avoid this problem.
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.
not super familiar with Rust but isn't Option<T> just an union type of null and T? I get the language has special semantics for this compared to a union type but it is conceptionally just an union.
For example this is something you can do with typescript.
For example this is something you can do with typescript.
function(args: Arguments) { ... }
type Arguments = { a: number, b: number } | { a: number, b: string, c: number }
> not super familiar with Rust but isn't Option<T> just an union type of null and T?
Only if there is a niche optimization happens if T is never null, otherwise it's a tagged union.
That's not what you're replying to is about.
Only if there is a niche optimization happens if T is never null, otherwise it's a tagged union.
That's not what you're replying to is about.
I'm pretty sure they're talking about reference counting that depends on the arguments, not about optional arguments or invalid argument combinations.
Thx for the work you're doing! Just out of curiosity, I sometimes struggle to write performant C# Godot code because it's hard to interface with the engine without doing a lot of back and forth conversions to engine types. You end up doing a lot of allocations. Did you run into that kind of stuff while creating your bindings?
My understanding may be out of date, but the C# support was created before GDExtension existed. The team has been working hard on porting it over to GDExtension. Once they are done, it should be much more performant, and they will finally be able to ship only one version of the editor. I believe the original C# bindings do a lot of unnecessary marshaling at the ABI.
With GDExtension, the core builtin types like `Vector3` are passed by value. Avoid unnecessarily wrapping them in Variant, a specialized tagged union, where you can. You can see the documentation here; you have direct access to the float fields: https://gdzig.github.io/gdzig/#gdzig.builtin.vector3.Vector3
Engine objects are passed around as opaque pointers into engine managed memory. The memory for your custom types is managed by you. You allocate the engine object and essentially attach userdata to it, tagged with a unique token provided to your extension. You can see the header functions that manage this: https://github.com/godotengine/godot/blob/e67074d0abe9b69f3d...
But, this is how the lifetimes for the objects gets slightly hairy (for us, the people creating the language bindings). Our goal with the Zig bindings is to make the allocations and lifetimes extremely obvious, a la Zig's philosophy of "No hidden memory allocations". It is proving somewhat challenging, but I think we can get there.
There's still a lot of surprising or unintuitive allocations that can happen when calling into Godot, but we hope to expose those. My current idea is to accept a `GodotAllocator` on those functions (and do nothing with it; just use it to signal the allocation). You can read the code for the `GodotAllocator` implementation: https://github.com/gdzig/gdzig/blob/master/gdzig/heap.zig#L8...
If we succeed, I think Zig can become the best language to write highly performant Godot extensions in.
With GDExtension, the core builtin types like `Vector3` are passed by value. Avoid unnecessarily wrapping them in Variant, a specialized tagged union, where you can. You can see the documentation here; you have direct access to the float fields: https://gdzig.github.io/gdzig/#gdzig.builtin.vector3.Vector3
Engine objects are passed around as opaque pointers into engine managed memory. The memory for your custom types is managed by you. You allocate the engine object and essentially attach userdata to it, tagged with a unique token provided to your extension. You can see the header functions that manage this: https://github.com/godotengine/godot/blob/e67074d0abe9b69f3d...
But, this is how the lifetimes for the objects gets slightly hairy (for us, the people creating the language bindings). Our goal with the Zig bindings is to make the allocations and lifetimes extremely obvious, a la Zig's philosophy of "No hidden memory allocations". It is proving somewhat challenging, but I think we can get there.
There's still a lot of surprising or unintuitive allocations that can happen when calling into Godot, but we hope to expose those. My current idea is to accept a `GodotAllocator` on those functions (and do nothing with it; just use it to signal the allocation). You can read the code for the `GodotAllocator` implementation: https://github.com/gdzig/gdzig/blob/master/gdzig/heap.zig#L8...
If we succeed, I think Zig can become the best language to write highly performant Godot extensions in.
Another thing it does badly and I am not sure if they are sorting out with the new design, is the magic methods crap.
They had to copy that bad idea from Unity, where methods are named in a specific way and then extracted via reflection.
Either provide specific interfaces that components have to implement, use attributes, or make use of generics with type constraints.
Maybe for Unity that made sense as they started with scripting languages, and then bolted on Mono on the side, but it never made sense to me.
They had to copy that bad idea from Unity, where methods are named in a specific way and then extracted via reflection.
Either provide specific interfaces that components have to implement, use attributes, or make use of generics with type constraints.
Maybe for Unity that made sense as they started with scripting languages, and then bolted on Mono on the side, but it never made sense to me.
> extracted via reflection
I think you are talking about dispatch of virtual methods, which is still a thing, but the performance cost can be somewhat mitigated.
the names of the methods are interned strings (called `StringName`). a naive implementation will allocate the `StringName`, but you can avoid the allocation with a static lifetime string. we expose a helper for comptime strings in Zig[0].
then, extension classes need to provide callback(s)[1] on registration that lookup and call the virtual methods. as far as I know, the lookup happens once, and the engine stores the function pointer, but I haven't confirmed this yet. it would be unfortunate if not.
at least right now in GDZig, though this might change, we use Zig comptime to generate a unique function pointer for every virtual function on a class[2]. this implementation was by the original `godot-zig` author (we are a fork). in theory we could inline the underlying function here with `@call(.always_inline)` and avoid an extra layer indirection, among other optimizations. it is an area I am still figuring out the best approach for
virtual methods are only ever necessary when interfacing with the editor, GDScript, or other extensions. don't pay the cost of a virtual method when you can just use a plain method call without the overhead.
[0]: https://gdzig.github.io/gdzig/#gdzig.builtin.string_name.Str...
[1]: https://github.com/godotengine/godot/blob/e67074d0abe9b69f3d...
[2]: https://github.com/gdzig/gdzig/blob/5abe02aa046162d31ed5c52f...
I think you are talking about dispatch of virtual methods, which is still a thing, but the performance cost can be somewhat mitigated.
the names of the methods are interned strings (called `StringName`). a naive implementation will allocate the `StringName`, but you can avoid the allocation with a static lifetime string. we expose a helper for comptime strings in Zig[0].
then, extension classes need to provide callback(s)[1] on registration that lookup and call the virtual methods. as far as I know, the lookup happens once, and the engine stores the function pointer, but I haven't confirmed this yet. it would be unfortunate if not.
at least right now in GDZig, though this might change, we use Zig comptime to generate a unique function pointer for every virtual function on a class[2]. this implementation was by the original `godot-zig` author (we are a fork). in theory we could inline the underlying function here with `@call(.always_inline)` and avoid an extra layer indirection, among other optimizations. it is an area I am still figuring out the best approach for
virtual methods are only ever necessary when interfacing with the editor, GDScript, or other extensions. don't pay the cost of a virtual method when you can just use a plain method call without the overhead.
[0]: https://gdzig.github.io/gdzig/#gdzig.builtin.string_name.Str...
[1]: https://github.com/godotengine/godot/blob/e67074d0abe9b69f3d...
[2]: https://github.com/gdzig/gdzig/blob/5abe02aa046162d31ed5c52f...
That and the exposition of _Something methods in C#, which don't follow C# conventions, private/protected methods have keywords for that.
Thanks for the overview.
Thanks for the overview.
I did not know this was a project that was in progress, and its quite exciting. I love Godot, and am quite fond a Zig as well. I'll be keeping my eye on this.
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.GTK having this kind of scheme is why Vala was made and inspired by C# but uses GObject and all its joys, then transpiles your code to C.
This is why a surprising number of GTK applications (more than I realized) are coded in Vala. I lowkey wish they had just adopted D instead of building up Vala. D is basically compiled C# to me in its own ways.
This is why a surprising number of GTK applications (more than I realized) are coded in Vala. I lowkey wish they had just adopted D instead of building up Vala. D is basically compiled C# to me in its own ways.
The GTK C API definitely feels like it's begging for a domain-specific language. I guess that language turned out to be Vala, and from what I could see it was a pretty nice language.
My takeaway from all this is a little bit different though: I feel this whole situation ultimately some credence to the Scheme/Racket philosophy, where you can effectively make yourself a domain-specific language without ever leaving the base language. In an alternate universe, we don't choose between adopting D or inventing Vala. We can just stay in Racket.
My takeaway from all this is a little bit different though: I feel this whole situation ultimately some credence to the Scheme/Racket philosophy, where you can effectively make yourself a domain-specific language without ever leaving the base language. In an alternate universe, we don't choose between adopting D or inventing Vala. We can just stay in Racket.
The problem is that D community keeps pivoting all the time, so now you get compiled C# with the breath of .NET ecosystem and IDE tooling, and is almost impossible to sell D, even if still has the edge in a few language features.
I'm not talking about merging .NET into D I'm talking about instead of building Vala which transpiles to C, the creators of Vala could have just made a D library instead. D does not need the .NET ecosystem to survive.
Neither am I.
D needs a usable ecosystem, the point is that since Andrei Alexandrescu's book came out, the incomplete pivots have allowed the competition to get most of D features where it had an edge back 15 years ago.
Even Andrei eventually got back to C++, now working at NVidia.
Native AOT or .NET Native, plus all the Midori related improvements, and everything else C# has access to, was one example, there are others from other ecosystems.
D needs a usable ecosystem, the point is that since Andrei Alexandrescu's book came out, the incomplete pivots have allowed the competition to get most of D features where it had an edge back 15 years ago.
Even Andrei eventually got back to C++, now working at NVidia.
Native AOT or .NET Native, plus all the Midori related improvements, and everything else C# has access to, was one example, there are others from other ecosystems.
Ah I understand. Yeah, what D needs is to build up a STD lib comparable to Go’s which lets you build nearly anything OOTB without a fuzz.
Giving in a bad system is more pragmatic rather than good
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 ;)
Kinda reminds me of a quote attributed to Bjarne Stroustrup:
"There are only two kinds of programming languages: those people always bitch about and those nobody uses"
I feel there are no absolutely "good" systems, only the ones with added compromises over time. Battle scars on a beautiful body.
"There are only two kinds of programming languages: those people always bitch about and those nobody uses"
I feel there are no absolutely "good" systems, only the ones with added compromises over time. Battle scars on a beautiful body.
No, it is about doing what you can, with what you have, where you are. That is good.
Since you can do both (you're reading a post about a RE-write) your 1-dimensional framework doesn't help deciding what is good
If you believe everything around you must be good before you can do good, then you must trick yourself into believing imperfect things are good to do anything, or withdraw completely from the world. Your radical philosophy leads either to delusion or isolation and inaction. Just do what you can.
The two terms aren’t mutually exclusive
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
“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.
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.
>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?
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?
> 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.
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.
You didn't cover it but is Ghostty still entirely dependent on libadwaita for most of its UI features? I completely lost interest when it was still in beta and I found out many features were disabled on Linux if you didn't want it to look and behave as a Gnome app.
Yes, its a hard dependency. But we go out of our way to add CSS classes to our UI widgets and even have a configuration in Ghostty to supply custom CSS directly (without you having to mess with gsettings or anything). We've seen some pretty incredible customizations in our showcase channel in Discord.
We haven't committed to our CSS classes yet as a stable API but we plan to do that in the next release cycle. Still, they haven't changed much in a year. :)
We haven't committed to our CSS classes yet as a stable API but we plan to do that in the next release cycle. Still, they haven't changed much in a year. :)
> CSS classes
GTK has gotten so fat that it's more like a 2nd-rate Electron. Not that Electron would have done Ghostty any good...
I have a bad feeling that the only decent & consistent UI option under Linux is to target Win32 API, then run it under Wine.
GTK has gotten so fat that it's more like a 2nd-rate Electron. Not that Electron would have done Ghostty any good...
I have a bad feeling that the only decent & consistent UI option under Linux is to target Win32 API, then run it under Wine.
The negative aspects of Electron have little to nothing to do with CSS, and you're only invoking it here to poison the well by association.
You are projecting. Personally speaking, I would choose Electron waaaay before I'd choose GTK. That probably wasn't an option for his optimized terminal, but would be Good Enough™ for just about anything else.
What does this have to do with Ghostty?
Are we looking at the same title?
We rewrote the Ghostty *G* *T* *K* application
The article about struggling... with GTK.
We rewrote the Ghostty *G* *T* *K* application
The article about struggling... with GTK.
You didn't explain anything wrong with GTK. You just brought up Electron out of nowhere.
Electron is bringing an entire web browser in to provide a cross-platform user interface. GTK has become almost a web browser to provide a cross-platform user interface. That is why I started off with
> CSS classes
To spell it out, I think it is all excessive.
> CSS classes
To spell it out, I think it is all excessive.
I don't think you know enough about GTK if you think having a CSS parser is bloat in a UI toolkit versus a whole theming engine.
Their CSS implementation is broader than what most actual browsers had 10 years ago. I would not have commented if I weren't already painfully familiar.
https://docs.gtk.org/gtk3/css-overview.html
It even has a DOM inspector window:
https://askubuntu.com/questions/597259/how-do-i-open-gtk-ins...
https://docs.gtk.org/gtk3/css-overview.html
It even has a DOM inspector window:
https://askubuntu.com/questions/597259/how-do-i-open-gtk-ins...
[deleted]
> GTK is by various definitions the most popular, widespread GUI toolkit on Linux that makes your app fit into _most_ ecosystems.
I disagree. Qt is also quite popular and much better at adapting to the environment it runs in.
I disagree. Qt is also quite popular and much better at adapting to the environment it runs in.
This is really just my opinion but I always can’t tell when an app uses QT and not positively. QT just looks uglier and feels more windows XP-esque than GTK apps
Gtk is more than Gnome. It is also used by Xfce and other DEs. So while Qt is also popular, I think it's fair to call it the most popular.
How about wxWidgets or Tcl/Tk or Fyne?
This is where your fork can come in
I like Linux because it gives me the freedom to make my system behave how I want. The GNOME devs seem to think that GNOME should only behave how they want. For example, last time I checked, GNOME required a third-party plugin just to move the clock from the center of the status bar to the side.
I'm not at all surprised to see that this mindset extends to GTK.
I'm not at all surprised to see that this mindset extends to GTK.
> The GNOME devs seem to think that GNOME should only behave how they want.
For many years I followed this whole outrage but wasn't really sure whom to believe because I didn't have any stakes in the matter. Then the GNOME/GTK devs removed support for key themes[0,1] and I still have no idea why. The arguments they brought forward make absolutely no sense to me.
Now I get where people were coming from.
[0]: https://old.reddit.com/r/emacs/comments/c22ff1/gtk_4_support...
[1]: https://news.ycombinator.com/item?id=35702303
For many years I followed this whole outrage but wasn't really sure whom to believe because I didn't have any stakes in the matter. Then the GNOME/GTK devs removed support for key themes[0,1] and I still have no idea why. The arguments they brought forward make absolutely no sense to me.
Now I get where people were coming from.
[0]: https://old.reddit.com/r/emacs/comments/c22ff1/gtk_4_support...
[1]: https://news.ycombinator.com/item?id=35702303
Sun donated a bunch of UI guidelines to the GNOME project back in the really early days. Those guidelines basically boiled down to "You users are idiots, and power users don't matter, so get rid of as many options and force a single way of interacting with the software." The GNOME development philosophy just expanded on this.
Gnome shell is designed in a way so that users can configure basically everything using plugins. That way everything does not have to go through the Gnome Shell developers and much more specific and esoteric functionality can be added.
Writing Gnome Shell extensions is easy, they're just JS scripts...
If you really need to move your clock with a bunch of clicks, there's also KDE which is less opinionated...
If you really need to move your clock with a bunch of clicks, there's also KDE which is less opinionated...
Can you do that on Windows/mac?
Gnome devs not withstanding, you have access to the source to change it if you want or put up a PR?
Gnome devs not withstanding, you have access to the source to change it if you want or put up a PR?
Being able to make a small change is good when every thing is well defined small parts. You can change the part you want and then use everything else as per normal. If everything is so tightly integrated that you end up having to maintain a fork of a large project, it doesn't work out so well.
I don't know which is true for this particular case, but I'd hazard a guess that it is a much bigger task than it needs to be.
I have seen Gnome devs talk of removing features because people were using them the wrong way. Not that people weren't using the features at all, just not for the purpose for which they were written. Experiences like that make me think that pull requests wouldn't get you very far either.
I don't know which is true for this particular case, but I'd hazard a guess that it is a much bigger task than it needs to be.
I have seen Gnome devs talk of removing features because people were using them the wrong way. Not that people weren't using the features at all, just not for the purpose for which they were written. Experiences like that make me think that pull requests wouldn't get you very far either.
You can look at the code of an extension that does the move, if you want an idea of what the level of effort is: https://github.com/kuvaus/moveclock
You can't put up a PR if the gate keepers reject your whole design approach
As a gatekeeper in an unrelated small project, I understand gatekeepers being selective. You have a vision, design standards, quality standards. Drive-by PRs that add "just this one thing I need" features is how your well-designed, cohesive project becomes a kitchen sink of shit.
> You have a vision, design standards, quality standards.
Unless, of course, all of those are shit, so a more design-competent person can drive by with an improvement, which will be rejected because it's too shiny
Unless, of course, all of those are shit, so a more design-competent person can drive by with an improvement, which will be rejected because it's too shiny
Well, yeah. They have their own design approach, if you don't take that into consideration, aren't you the one that in the wrong?
You're not, that depends entirely on the assessment of the relative approaches and whom you care more about, users or a subset of designers closest to the gates.
But that's beside the point, the point was the criticism of the "send a PR" even though that resolves nothing due to the mismatch.
But that's beside the point, the point was the criticism of the "send a PR" even though that resolves nothing due to the mismatch.
2025, still cannot have taskbar on left or right side in Windows 11.
I can do that on GNOME and macOS. And yes, with 21:9 it is very nice. With a vertical monitor or a 3:2 (Surface), not so much.
I can do that on GNOME and macOS. And yes, with 21:9 it is very nice. With a vertical monitor or a 3:2 (Surface), not so much.
You have to install an extension to do that on GNOME, likewise on Windows 11 you can use Explorer Patcher.
Both "monkey patch" the shell.
Both "monkey patch" the shell.
While I prefer tiling windows manager, GNOME’s approach is sensible. Restrain your features to a restricted default and allow users to extend it if they want to. The code is open and well organized as far as I can see. So it’s very easy to see where to extend from.
> just to move the clock from the center of the status bar to the side.
And I like linux because there are plenty of people who also do not care about this and want to just use their computer.
And I like linux because there are plenty of people who also do not care about this and want to just use their computer.
You can "just use" KDE too. The default are actually less insane than gnome, it's easier to use.
The idea that more functionality makes software less usable makes no sense to me. No, it's more usable.
Its like when people argue that iOS not allowing anything other than safari is a good thing.
Okay... how? Because if you like safari, nothing changes for you. You just keep using it. You wouldn't even be able to tell.
Similarly, if you like KDE you can just... use it. You don't actually have to change anything. There's no gun to your head. If you're the type of person who just takes software and uses it, then great - you don't need Gnome for that. KDE is actually better at that, IMO.
The idea that more functionality makes software less usable makes no sense to me. No, it's more usable.
Its like when people argue that iOS not allowing anything other than safari is a good thing.
Okay... how? Because if you like safari, nothing changes for you. You just keep using it. You wouldn't even be able to tell.
Similarly, if you like KDE you can just... use it. You don't actually have to change anything. There's no gun to your head. If you're the type of person who just takes software and uses it, then great - you don't need Gnome for that. KDE is actually better at that, IMO.
I hate GTK enough that I'm considering porting Ghostty to literally any other GUI system. I think that Qt is probably the only alternative that anyone might consider "platform native" so I'll probably go that direction, even though Qt development is rather special in its own way (you know how GTK decided C needed an object system? Qt decided that C++ needed a more better object system).
> Qt decided that C++ needed a more better object system
I haven't used Qt, nor C++, in many moons, but my understanding was that `moc` [1] filled a gap of run-time dynamicism that C++ didn't natively support when it was invented. Has C++ since evolved to make that obsolete? Seems like moc is still a thing.
[1] https://doc.qt.io/qt-6/moc.html
I haven't used Qt, nor C++, in many moons, but my understanding was that `moc` [1] filled a gap of run-time dynamicism that C++ didn't natively support when it was invented. Has C++ since evolved to make that obsolete? Seems like moc is still a thing.
[1] https://doc.qt.io/qt-6/moc.html
I feel some genuine grief about what GTK has become.
It started out as a toolkit for application development and leaned heavily into the needs of the C developer who was writing an application with a GUI. It was really a breath of fresh air to us crusties who started out with Xaw and Motif. That's the GTK I want to remember.
What it is now is (IMO) mostly a product of the economics of free software development. There's not a lot of bread out there to build a great, free, developer experience for Linux apps. Paid GTK development is just in service of improving the desktop platform that the big vendors ship. This leads to more abstraction breaks between the toolkit, the desktop, and the theme, because nobody cares as long as all the core desktop apps work. "Third party" app developers, who used to be the only audience for GTK, are a distant second place. The third party DX is only good if you follow a cookie-cutter app template.
I switched my long-term personal projects from GTK2 to Dear ImGui, which IMO is the only UI toolkit going that actually prioritizes developer experience. Porting from GTK2 to GTK3 would have been almost as much work since I depended on Clutter (which was at one point a key element of the platform, but got dropped/deprecated -- maybe its corporate sponsor folded? not sure).
It started out as a toolkit for application development and leaned heavily into the needs of the C developer who was writing an application with a GUI. It was really a breath of fresh air to us crusties who started out with Xaw and Motif. That's the GTK I want to remember.
What it is now is (IMO) mostly a product of the economics of free software development. There's not a lot of bread out there to build a great, free, developer experience for Linux apps. Paid GTK development is just in service of improving the desktop platform that the big vendors ship. This leads to more abstraction breaks between the toolkit, the desktop, and the theme, because nobody cares as long as all the core desktop apps work. "Third party" app developers, who used to be the only audience for GTK, are a distant second place. The third party DX is only good if you follow a cookie-cutter app template.
I switched my long-term personal projects from GTK2 to Dear ImGui, which IMO is the only UI toolkit going that actually prioritizes developer experience. Porting from GTK2 to GTK3 would have been almost as much work since I depended on Clutter (which was at one point a key element of the platform, but got dropped/deprecated -- maybe its corporate sponsor folded? not sure).
Oh, I would love it if Wayland provided a standard UI toolkit (server-side)! Is that a thing that happened when I wasn't looking?
I don't think we will even see universal support for server-side window decorations in our lifetime, so don't hold your breath ;)
(yes I'm aware of libdecor, but it sucks to have to pull in yet another complex dependency into clients)
(yes I'm aware of libdecor, but it sucks to have to pull in yet another complex dependency into clients)
While pulling in a library just for window decorations is insane, the same could make sense for a full UI toolkit - after all, that's how standard UI components have worked on e.g. Windows. In a way, Qt can already fulfill that role because by default it tries to adapt to the look and feel of the platform it runs on, including using GTK themes. Too bad that it's a bloated pig without a stable ABI that would allow you to use the system version.
> after all, that's how standard UI components have worked on e.g. Windows
Standard UI components on Windows are in user32.dll, and that's guaranteed to exist on each Windows installation all the way back to Windows NT.
And to just get an empty decorated window all I need to do is call CreateWindowEx() (which will always look consistent), all the rendering inside that window can then be done through one of the 3D APIs.
Same on macOS, I don't need any optional dependencies to create a decorated empty window which I can then render into with Metal.
For that same scenario (3D rendering into an empty window), Wayland only guarantees me a bare undecorated rectangle I can draw into with GL or Vulkan (and I wouldn't be surprised if even that is an optional feature I need to query first lol). And even if both GTK and Qt would be guaranteed to be installed on each Linux desktop system (so that I can pick one of two frameworks to give me a dedorated window, that would be overkill if I just want an empty window for 3D rendering - and even then I don't know if a window created through Qt would look consistent on a GNOME desktop or vice versa).
Of course that topic has been discussed to death without anybody who could fix that problem once and for all (by making the server-side decoration extension mandatory for desktop Linux systems) even recognizing that this is an issue that needs fixing.
Tbh, I don't even understand why desktop Linux needs more than a single Wayland implementation. So much wasted redundant work which could be put into actual improvements.
Standard UI components on Windows are in user32.dll, and that's guaranteed to exist on each Windows installation all the way back to Windows NT.
And to just get an empty decorated window all I need to do is call CreateWindowEx() (which will always look consistent), all the rendering inside that window can then be done through one of the 3D APIs.
Same on macOS, I don't need any optional dependencies to create a decorated empty window which I can then render into with Metal.
For that same scenario (3D rendering into an empty window), Wayland only guarantees me a bare undecorated rectangle I can draw into with GL or Vulkan (and I wouldn't be surprised if even that is an optional feature I need to query first lol). And even if both GTK and Qt would be guaranteed to be installed on each Linux desktop system (so that I can pick one of two frameworks to give me a dedorated window, that would be overkill if I just want an empty window for 3D rendering - and even then I don't know if a window created through Qt would look consistent on a GNOME desktop or vice versa).
Of course that topic has been discussed to death without anybody who could fix that problem once and for all (by making the server-side decoration extension mandatory for desktop Linux systems) even recognizing that this is an issue that needs fixing.
Tbh, I don't even understand why desktop Linux needs more than a single Wayland implementation. So much wasted redundant work which could be put into actual improvements.
AFAIK, both KDE and GNOME had an architecture already where they changed only the base layer to adapt to wayland. Wlroot have a different architecture. And that’s why you have three mainstream implementations.
Slightly unrelated, but I wonder why the "Linux desktop maintainers" (whoever that is - and that this is even a question is probably the main problem) haven't come up yet with a minimal shared 'interface library' that's mandatory on each Linux desktop installation, and which provides a standard API (but no implementation) to create a window, get input events and probably also a set of simple UI widgets (buttons, sliders, checkboxes, lists - basically what Win32 or X11 provides).
KDE, GTK or any other concrete UI toolkit register 'drivers/plugins' with this interface library to do the actual work.
Minimal 'framework-agnostic' UI apps can then use this standard shim library and always look fully native, while applications which require the full KDE or GTK feature set can still use those frameworks directly.
Call it Common Desktop Environment or something idk...
KDE, GTK or any other concrete UI toolkit register 'drivers/plugins' with this interface library to do the actual work.
Minimal 'framework-agnostic' UI apps can then use this standard shim library and always look fully native, while applications which require the full KDE or GTK feature set can still use those frameworks directly.
Call it Common Desktop Environment or something idk...
I’m not a maintainer, but IMO, it may be the different design systems. Yes there are common elements like buttons and scrolled view. But the whole selling point of a toolkit is consistency, especially around more advanced widgets.
> But the whole selling point of a toolkit is consistency, especially around more advanced widgets.
In theory yeah, but that consistency is out the window anyway when some apps I'm using are GTK, others Qt, and yet others Electron with the JS framework flavour of the week.
A standard shim library which would map to the user's preferred framework (e.g. GTK or Qt) would at least be visually consistent between GTK and Qt - and not just for the window chrome) - even if it only offers a common subset of GTK vs Qt vs ... features.
In theory yeah, but that consistency is out the window anyway when some apps I'm using are GTK, others Qt, and yet others Electron with the JS framework flavour of the week.
A standard shim library which would map to the user's preferred framework (e.g. GTK or Qt) would at least be visually consistent between GTK and Qt - and not just for the window chrome) - even if it only offers a common subset of GTK vs Qt vs ... features.
Why don't the developer do the shim themselves? You can always have a core and shell out the UI to the platform being used. One example is Celluloid [0] (GTK) and IINA [1], both use mpv as their backend. Why not have something like libslack, libspotify (a real one), or libdiscord, then have a more appropriate frontend to meet the users where they are.
[0]: https://celluloid-player.github.io/
[1]: https://iina.io/
[0]: https://celluloid-player.github.io/
[1]: https://iina.io/
...more code in the client that should really be part of the 'operating system', and if I need to do it myself anyway, why should I care about consistency with other applications?
Such an idea only works if it is less work for application developers, not more. And I think the right place for that is the operating system layer, not the application layer.
Such an idea only works if it is less work for application developers, not more. And I think the right place for that is the operating system layer, not the application layer.
No, there are no protocols intended to implement such a thing at this time. I'm not aware of anybody attempting to spec out such a protocol either, but I do think it's a really interesting idea.
Edit: s/protocol/interface
Edit: s/protocol/interface
There is about zero chance that Gnome would implement such a protocol which makes the whole endeavor pointless. They can't even agree on server side window decorations.
How would this work given that the major DE's have completely different UX and design?
That's precisely the point! It would be really nice for applications to be able to operate agnostic from the DE's decisions about UX and design. Applications want something much more high level: button here, scroll bar there, text input here. It's the DE's job to make such things accessible and look pretty. If you think about it, that's precisely why the web is a popular user interface target: the application has a much higher level interface, and all those concerns are, correctly, handled at a different abstraction layer.
I don’t think it’s possible to build a generic UI across DEs, at least if you actually want them to feel native. They’ve all got different standards, so while Gnome might have a button here, a text box here, and scroll bar there on KDE a scroll bar here, text box here, and then the button might make more sense.
My point is that the application doesn't have to care if it's running in Gnome or KDE. It just speaks Wayland protocol and then it gets a Window and some UI in it. The gnome window manager / KDE window manager then makes that UI properly native.
Consider input methods. That clearly belongs in the window manager process, not each application process. The application should simply ask for a text box, and then receive events when the text in the box changes. The fact that I'm typing Japanese into a fancy UI shouldn't make any difference to the application, other than what text it receives from the widget events.
And that should all be possible in a small, static executable, that is speaking the Wayland protocol, and has zero dependencies other than networking syscalls.
Consider input methods. That clearly belongs in the window manager process, not each application process. The application should simply ask for a text box, and then receive events when the text in the box changes. The fact that I'm typing Japanese into a fancy UI shouldn't make any difference to the application, other than what text it receives from the widget events.
And that should all be possible in a small, static executable, that is speaking the Wayland protocol, and has zero dependencies other than networking syscalls.
> makes that UI properly native
That's five words with unimaginable complexity.
That's five words with unimaginable complexity.
I like the idea but, having built many UIs for many different applications over the years, I doubt it would work for anything non-trivial. The thing is, as soon as your UI reaches a certain level of complexity you need tight control over the look and feel, especially over the positioning of UI components relative to each other. Unfortunately, the latter depends a lot on how exactly your UI components look and behave.
For example, your text input box's label might be displayed to the left of the box, to the top, or it might be one of those floating labels that are displayed inside the box but move to the top border as soon as you focus the box. Depending on that, you would choose the spacing to neighboring text boxes and buttons differently, and maybe also arrange things differently altogether, because of different space requirements.
In other words: Your application would need to know what exactly the Wayland "UI layer" is going to display in order to send it precise instructions. But then your abstraction is very leaky.
For example, your text input box's label might be displayed to the left of the box, to the top, or it might be one of those floating labels that are displayed inside the box but move to the top border as soon as you focus the box. Depending on that, you would choose the spacing to neighboring text boxes and buttons differently, and maybe also arrange things differently altogether, because of different space requirements.
In other words: Your application would need to know what exactly the Wayland "UI layer" is going to display in order to send it precise instructions. But then your abstraction is very leaky.
No it is the developer's job to make things be nice and work well. We've gone past pretending to be native shit for pretty much everything. We define our own design styles and language since the web took off.
Server side ui toolkit doesnt make much sense to me. Better idea is to target some multimedia layer like web browser, electron, etc ... Or just hope someone someday comes up with UI library that doesnt suck.
In my view the primary reason for GTK’s prominence on Linux rides on one thing primarily: it’s got C bindings, and thus it has decent bindings for just about every other language under the sun too. If you’re not trying for anything fancy, these bindings can even be auto-generated.
The runner up Qt is much more tightly tied to C++ and Python to its detriment. You really need to meet devs where they’re at instead of insisting that they adopt a particular language to use your UI toolkit.
Aside from that, at the end of the day, if you’re building a full fat complex desktop app an old style imperative UI toolkit is probably one of the more practical choices you can make. They have an exhaustive set of battle tested, accessible widgets built in and their pitfalls are well known. Newer approaches expect you to write or import everything and start requiring increased contortions from the developer past a certain point of complexity.
The runner up Qt is much more tightly tied to C++ and Python to its detriment. You really need to meet devs where they’re at instead of insisting that they adopt a particular language to use your UI toolkit.
Aside from that, at the end of the day, if you’re building a full fat complex desktop app an old style imperative UI toolkit is probably one of the more practical choices you can make. They have an exhaustive set of battle tested, accessible widgets built in and their pitfalls are well known. Newer approaches expect you to write or import everything and start requiring increased contortions from the developer past a certain point of complexity.
Actually the auto generated bindings can be attributed to the gobject system. It's a very interesting system, similar DCOM in Windows.
Too bad it's so poorly documented. It seems to me like advanced technology left over from a dead civilization, that's being handled by cave people.
Too bad it's so poorly documented. It seems to me like advanced technology left over from a dead civilization, that's being handled by cave people.
GStreamer: https://gstreamer.freedesktop.org/ is written in GObject which enabled some great tooling like gst-inspect-1.0:
https://gstreamer.freedesktop.org/documentation/tools/gst-in...
And it's so flexible that LIGO (the gravitational wave observatory) uses it to analyze the data: https://dcc-llo.ligo.org/public/0168/P2000195/004/ms.pdf
COM, not DCOM, that would be D-BUS.
Qt licensing is annoying, GTK has its downsides.
So we are left with Electron…
So we are left with Electron…
Aren't GTK and Qt (community edition) both LGPL (though different versions)?
So Electron does not have downsides? Like far worse platform integration.
So Electron does not have downsides? Like far worse platform integration.
Well Qt license is not annoying.
Qt the company is annoying because they make it super hard to use community edition and it is super annoying having per developer licensing with all kinds of super annoying BS one have to deal with when developing for Qt.
For Electron I can get 20 devs hired tomorrow or I myself can start project right away and be up and running in minutes.
Qt the company is annoying because they make it super hard to use community edition and it is super annoying having per developer licensing with all kinds of super annoying BS one have to deal with when developing for Qt.
For Electron I can get 20 devs hired tomorrow or I myself can start project right away and be up and running in minutes.
Yep, externalization of costs, make it easier for yourself and shittier for the user. Well done ;).
That said, Electron has made the number of Linux apps go up, which is a win. Still highly prefer native macOS apps on Mac and GTK/Qt apps on Linux, but I know that's a losing battle.
That said, Electron has made the number of Linux apps go up, which is a win. Still highly prefer native macOS apps on Mac and GTK/Qt apps on Linux, but I know that's a losing battle.
Did you know about Slint https://slint.dev ? What do you think about it?
I don’t think any UI framework with a license more restrictive or complicated than full on MIT/BSD is going to be able to compete toe to toe with Electron. It doesn’t matter what the price tag is, if it has one it’s going to lose in a shootout between the two.
The only exception I can imagine is maybe a framework that uses the Unreal model, where it’s free to use under USD$1m/year in revenue and beyond that requires only a modest fee.
The only exception I can imagine is maybe a framework that uses the Unreal model, where it’s free to use under USD$1m/year in revenue and beyond that requires only a modest fee.
>> Well Qt license is not annoying.
Qt is a hodgepodge of many different components which have different licenses. This is made worse by Qt being an application development framework and not just a GUI toolkit. It includes much more than necessary and a lot of apps will use those other features and become tightly coupled with Qt. Not that its easy to switch toolkits, but it can be extra hard to move away from Qt.
Qt is a hodgepodge of many different components which have different licenses. This is made worse by Qt being an application development framework and not just a GUI toolkit. It includes much more than necessary and a lot of apps will use those other features and become tightly coupled with Qt. Not that its easy to switch toolkits, but it can be extra hard to move away from Qt.
I still rather deal with either Qt or Gtk, even though Web pays the bills.
No one is pointing guns forcing people to write Electron crap.
No one is pointing guns forcing people to write Electron crap.
> 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
I'm curious what the main opposing opinion you've hit there is? Is it accessibility and non-roman-alphabet input? Those are the things that kinda stand out to me as "gtk does this pretty well, and most developers who hand-roll stuff wouldn't think about it".
I'm curious what the main opposing opinion you've hit there is? Is it accessibility and non-roman-alphabet input? Those are the things that kinda stand out to me as "gtk does this pretty well, and most developers who hand-roll stuff wouldn't think about it".
> 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).
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).
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.
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.
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.
> 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.
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.
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.
https://bugzilla.gnome.org/show_bug.cgi?id=750994
There are no plans for a fix. The maintainer recommends waiting for Wayland.
From what I can tell, that's an XInput2 bug, not a GTK bug. I suppose GTK can try to implement workarounds like the Chromium heuristic (https://issues.chromium.org/issues/41243294) but the problem lies upstream.
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.
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.
Other toolkits don't seem to have this issue on X11.
those toolkits do not support smooth scrolling.
The issue comes from XInput2 (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
The issue comes from XInput2 (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
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'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
Bit it's also the most mentioned issue: https://github.com/ghostty-org/ghostty/issues/189
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.
I love 99% of what Ghostty brings to the table as a terminal replacement but the copy / paste issues with it are incredibly frustrating and I run into them almost daily.
I can't even open nano in ghostty when I've ssh'd to my ubuntu box:
$ nano
Error opening terminal: xterm-ghostty.
If you're like a quick fix, see https://ghostty.org/docs/help/terminfo#copy-ghostty's-termin.... If that doesn't work, perhaps one of the other suggestions on that page will.
Might be $TERM needs to be set or you need to add ghostty to terminfo
> Might be $TERM needs to be set or you need to add ghostty to terminfo
Yeah, except that the specific terminfo needed for ghostty isn't installed anywhere on the boxes you ssh into ... you need to manually install it on every single one of them.
That in and of itself makes it truly painful to switch to ghostty.
And there are still a lot of other issues, like e.g. building the tip is a freaking nightmare of dependencies and weird issues (hard reliance on specific versions of the zig compiler and of something called "blueprint compiler", etc...)
Not ready for prime time by a mile IMO.
Yeah, except that the specific terminfo needed for ghostty isn't installed anywhere on the boxes you ssh into ... you need to manually install it on every single one of them.
That in and of itself makes it truly painful to switch to ghostty.
And there are still a lot of other issues, like e.g. building the tip is a freaking nightmare of dependencies and weird issues (hard reliance on specific versions of the zig compiler and of something called "blueprint compiler", etc...)
Not ready for prime time by a mile IMO.
> the specific terminfo needed for ghostty isn't installed anywhere on the boxes you ssh into ... you need to manually install it on every single one of them.
Yeah this is going to be an issue with any of the newer terminal emulators. No big deal. Updating terminfo is easy. If you can't then just set TERM=xterm
> Not ready for prime time by a mile IMO.
Nah, the issue is your lack of experience and understanding of the basics is terminals.
Yeah this is going to be an issue with any of the newer terminal emulators. No big deal. Updating terminfo is easy. If you can't then just set TERM=xterm
> Not ready for prime time by a mile IMO.
Nah, the issue is your lack of experience and understanding of the basics is terminals.
> Updating terminfo is easy.
lol.
sure, very easy to do this on order of magnitude 1000 remote machines whose various OS's are entirely managed by automation.
lol.
sure, very easy to do this on order of magnitude 1000 remote machines whose various OS's are entirely managed by automation.
I don't think you've used Ghostty in a while. It has auto installing terminfo when ssh-ing.
Also, every program ever depends on a certain version of a compiler, so I don't understand this complaint. Ghostty requires Zig 0.14. That's it, not a specific compiler hash. blueprint-compiler is packaged for pretty much every distribution these days.
Also, every program ever depends on a certain version of a compiler, so I don't understand this complaint. Ghostty requires Zig 0.14. That's it, not a specific compiler hash. blueprint-compiler is packaged for pretty much every distribution these days.
I'm not sure how the fact that it's complicated to compile makes it unready for prime time.
As for $TERM, you can simply default it to `xterm-256color` which is more than enough
As for $TERM, you can simply default it to `xterm-256color` which is more than enough
Or just "export TERM=xterm-256color". Lose support for Ghostty-specific features, but get the subset that works everywhere.
This. See the ghostty documentation: https://ghostty.org/docs/help/terminfo#ssh
I spend like half of my time in the terminal and search is an absolute deal breaker for me. Guys have created an incredibly cool terminal and surely they use it a lot but they... just don't search? I have nothing but respect and admiration for the project, just wondering what their day to day terminal usage experience looks like if they don't need to look for things.
This could be a valid bug that you can report
No command f is the killer for me
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.
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!
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!
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.
Rust's bindings fully embrace GTK's refcounting, so there's no mismatch in memory management.
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.
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.
This is a generic smart pointer. It had to be designed and verified manually, but that line of code has been written once 8 years ago, and nobody had to remember to write this FFI glue or even call this method since. It makes the public API automatically safe for all uses of all weak refs of all GTK types.
The Zig version seems to be a fix for one crash in a destructor of a particular window type. It doesn't look like a systemic solution preventing weak refs crashes in general.
The Zig version seems to be a fix for one crash in a destructor of a particular window type. It doesn't look like a systemic solution preventing weak refs crashes in general.
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?
Yeah, Rust isn't OOP, which is usually fine or even an advantage, but GUIs are one case where it hurts, and there isn't an obvious alternative.
> gtk-rs you are pulling in 100+ crate dependencies and who knows what lurks in those?
gtk-rs is a GNOME project. A lot of it is equivalent to .h files, but each file is counted as a separate crate. The level of trust or verification required isn't that different, especially if pulling a bunch of .so files from the same org is uncontroversial.
Cargo keeps eliciting reactions to big numbers of "dependencies", because it gives you itemized lists of everything being used, including build deps. You just don't see as much inner detail when you have equivalent libs pre-built and pre-installed.
Crates are not the same unit as a typical "dependency" in the C ecosystem. Many "dependencies" are split into multiple crates, even when it's one codebase in one repo maintained by one person. Crates are Rust's compilation unit, so kinda like .o files, but not quite comparable either.
A Cargo Workspace would be conceptually closer to a typical small C project/dependency, but Cargo doesn't support publishing Workspaces as a unit, so every subdirectory becomes a separate crate.
> gtk-rs you are pulling in 100+ crate dependencies and who knows what lurks in those?
gtk-rs is a GNOME project. A lot of it is equivalent to .h files, but each file is counted as a separate crate. The level of trust or verification required isn't that different, especially if pulling a bunch of .so files from the same org is uncontroversial.
Cargo keeps eliciting reactions to big numbers of "dependencies", because it gives you itemized lists of everything being used, including build deps. You just don't see as much inner detail when you have equivalent libs pre-built and pre-installed.
Crates are not the same unit as a typical "dependency" in the C ecosystem. Many "dependencies" are split into multiple crates, even when it's one codebase in one repo maintained by one person. Crates are Rust's compilation unit, so kinda like .o files, but not quite comparable either.
A Cargo Workspace would be conceptually closer to a typical small C project/dependency, but Cargo doesn't support publishing Workspaces as a unit, so every subdirectory becomes a separate crate.
Rust has all the features to do COM and CORBA like OOP.
As Windows proves, it is more than enough to write production GUI components, and the industry leading 3D games API, since the days of Visual Basic 5.
In fact that is how most new Rust components on Windows by Microsoft have been written, as COM implementations.
As Windows proves, it is more than enough to write production GUI components, and the industry leading 3D games API, since the days of Visual Basic 5.
In fact that is how most new Rust components on Windows by Microsoft have been written, as COM implementations.
I remember it being bad enough for a project I was working on that the engineer working on it switched to relm: https://relm4.org
It is built on top of gtk4-rs, and fairly usable: https://github.com/hackclub/burrow/blob/main/burrow-gtk/src/...
I'm sure the gtk-rs bindings are pretty good, but I do wonder if anyone ran Valgrind on them. When it comes to C interop, Rust feels weirdly less safe just because of the complexity.
It is built on top of gtk4-rs, and fairly usable: https://github.com/hackclub/burrow/blob/main/burrow-gtk/src/...
I'm sure the gtk-rs bindings are pretty good, but I do wonder if anyone ran Valgrind on them. When it comes to C interop, Rust feels weirdly less safe just because of the complexity.
But the GTK-rs stuff has already abandoned GTK3. Wait... I guess if the GTK-rs API doesn't change and it just uses GTK4 that's a good way to go? Everyone can install both 3 and 4 on their system and the rust apps will just migrate. Is that how they did it?
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? ;)
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? ;)
[deleted]
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.
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?
> 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?
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.
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.
> 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.
Calling it a "safe" wrapper, when that safety is entirely dependent on (a) the correctness of the hand-written wrapper, (b) the safety of the underlying FFI code, has always been a huge stretch of terminology. It's more like a veil of safety, so we can shield our modest eyes from impure code that flaunts its unsafeness.
Rust has no magical ways of turning unsafe code safe, nor is it in any way special in being able to create statically-verifiable abstractions around an unsafe core.
Don't get me wrong, Rust is memory safe when used as a cohesive system, and I would encourage its use as such where memory safety is desired. But the idea of "safely" wrapping unsafe FFIs reminds me of the idea of packaging underwater mortgages into mortgage-backed securities and selling them as a safe investment.
Calling it a "safe" wrapper, when that safety is entirely dependent on (a) the correctness of the hand-written wrapper, (b) the safety of the underlying FFI code, has always been a huge stretch of terminology. It's more like a veil of safety, so we can shield our modest eyes from impure code that flaunts its unsafeness.
Rust has no magical ways of turning unsafe code safe, nor is it in any way special in being able to create statically-verifiable abstractions around an unsafe core.
Don't get me wrong, Rust is memory safe when used as a cohesive system, and I would encourage its use as such where memory safety is desired. But the idea of "safely" wrapping unsafe FFIs reminds me of the idea of packaging underwater mortgages into mortgage-backed securities and selling them as a safe investment.
But that wrapper clearly delineates two, previously mixed domain of bugs, reducing the complexity of understanding any "line".
It's much much easier to say that a reference is alive here, and only here can we derefence it, AND every other business code elsewhere.
It's much much easier to say that a reference is alive here, and only here can we derefence it, AND every other business code elsewhere.
> Rust has no magical ways of turning unsafe code safe
Fully agreed on that -- the unsafe keyword means it's unsafe.
> nor is it in any way special in being able to create statically-verifiable abstractions around an unsafe core.
This isn't really true. Rust's type system has:
- Affine types
- Lifetimes
- Borrowed and exclusive references
- Thread-safety
- Explicit delineation between safe and unsafe code -- with no UB in safe code, and a (cultural) design principle that unsafe code is not allowed to make unchecked assumptions about the behavior of safe code
Most mainstream languages do not have any one of these features, let alone all of them. Thus, Rust's ability to "create statically-verifiable abstractions around an unsafe core" is in practice far more powerful than in C, C++, or Zig. You certainly have the ability to create some such abstractions in other languages, but you cannot statically verify nearly as many properties. (And of course there are languages like SPARK that can verify even more statically than Rust.)
In my experience, as a systems programmer who heavily uses Rust to interact with FFI, hardware MMIO and DMA, interrupt handling, networking code, etc., Rust's ability to safely abstract unsafe primitives is easily the most practically useful aspect of the language. It's not a silver bullet that turns incorrect code into correct code, but it is incredibly good at verifying the correctness of a large application built from small low-level primitives. If you're interfacing with buggy C code, Rust certainly isn't going to help you much -- but it does makes a huge difference in preventing "you're holding it wrong" bugs when interacting with a C API.
An unsafe block declares an axiom: you're asserting to the compiler that you've verified (statically with the type system or dynamically with runtime assertions) all preconditions necessary for some primitive to be sound (free of UB). The compiler can then use that axiom to prove the soundness of all code that interacts with that primitive. When I write a driver to perform a DMA transfer, I only have to think through all the concurrency, alignment, lifetime, moveability, caching, and cancellation requirements once, and the compiler will check them for me every time I (or anyone else) use that driver in an application.
Fully agreed on that -- the unsafe keyword means it's unsafe.
> nor is it in any way special in being able to create statically-verifiable abstractions around an unsafe core.
This isn't really true. Rust's type system has:
- Affine types
- Lifetimes
- Borrowed and exclusive references
- Thread-safety
- Explicit delineation between safe and unsafe code -- with no UB in safe code, and a (cultural) design principle that unsafe code is not allowed to make unchecked assumptions about the behavior of safe code
Most mainstream languages do not have any one of these features, let alone all of them. Thus, Rust's ability to "create statically-verifiable abstractions around an unsafe core" is in practice far more powerful than in C, C++, or Zig. You certainly have the ability to create some such abstractions in other languages, but you cannot statically verify nearly as many properties. (And of course there are languages like SPARK that can verify even more statically than Rust.)
In my experience, as a systems programmer who heavily uses Rust to interact with FFI, hardware MMIO and DMA, interrupt handling, networking code, etc., Rust's ability to safely abstract unsafe primitives is easily the most practically useful aspect of the language. It's not a silver bullet that turns incorrect code into correct code, but it is incredibly good at verifying the correctness of a large application built from small low-level primitives. If you're interfacing with buggy C code, Rust certainly isn't going to help you much -- but it does makes a huge difference in preventing "you're holding it wrong" bugs when interacting with a C API.
An unsafe block declares an axiom: you're asserting to the compiler that you've verified (statically with the type system or dynamically with runtime assertions) all preconditions necessary for some primitive to be sound (free of UB). The compiler can then use that axiom to prove the soundness of all code that interacts with that primitive. When I write a driver to perform a DMA transfer, I only have to think through all the concurrency, alignment, lifetime, moveability, caching, and cancellation requirements once, and the compiler will check them for me every time I (or anyone else) use that driver in an application.
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`).
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`).
I vaguely remember that there is a new language that promises "Safety across FFI boundary", but can't recall the name
Rust would face similar issues. Its safety guarantees only apply within Rust code; the FFI boundary with C/GObject is inherently unsafe and requires manual lifetime management. Rust's borrow checker can't verify external code's memory usage.
It is so much more difficult to write c bindings in rust.
Maybe they wouldn’t even be able to write gtk bindings in rust
Maybe they wouldn’t even be able to write gtk bindings in rust
gtk bindings in Rust have existed for like, ten years.
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.)
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.)
> 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.
- 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.
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?
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.
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.
Just from my basic understanding after working with sdl2 and gtk, sdl2 is more suitable for game development, It doesn't have standard set of UI elements. So every UI element, and interactions will have to be implemented by hand. Now imagine displaying a list view with huge number of items.
And the worst is, Terminals works with texts, sdl2, in my knowledge do not have proper way to display large amount of text, let alone select and copy.
There are probably other issues, these came from what I experienced
And the worst is, Terminals works with texts, sdl2, in my knowledge do not have proper way to display large amount of text, let alone select and copy.
There are probably other issues, these came from what I experienced
Unless you plan on writing your entire UI from scratch, like, from the framebuffer on up (in which case it will integrate poorly with the rest of the desktop) you must use one of the common widget toolkits: GTK or Qt. If you want the flexibility of not having to commit to C++, GTK is your only choice.
> including having more escape sequences result in more native GUI elements.
That’s how you invent HTML forms (those were modeled on IBM 3270)
That’s how you invent HTML forms (those were modeled on IBM 3270)
saved sessions in a tree style with folders would be a nice advanced feature!
> 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 (you’ll need “showdead” enabled, all of Kovid’s comments got flagged to death).
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 (you’ll need “showdead” enabled, all of Kovid’s comments got flagged to death).
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.
It’s like the “WebKit” for terminal, as I understand it.
Anyone could drop-in libghostty, and immediately have a fully functional terminal.
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.
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.
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.)
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.
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
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.
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.
And someone already did: https://github.com/gabydd/wraith (Wayland-only frontend, extremely lightweight). Super cool.
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.
In the end it wasn't that messy, but probably confusing for anyone used to writing dogmatic GTK applications.
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
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 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.
> 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
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
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.
It's literally wasted because it's used for nothing useful. Also, you can have other apps that now can take up less area.
Titlebars are quite useful, I use them frequently to move, raise, lower, and maximize windows.
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
Nothing more “ergonomic” than a titlebar. Discoverable, standard, usable.
Many people use tiling window managers, so title bars become useless. The first thing I did in configuring ghostty was disabling window decoration for this reason.
Probably ten times more people don’t.
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.
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!
Good to hear the Mitchell and the team are still hacking away at it! Thanks for the great software!
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.
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.
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.
"native" here means using the same toolkit as the desktop environment.
There is no "native" compositor for Linux either. The most used one is the one that Android uses.
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.
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
Wouldn't Vala be a better option instead of Zig?
> 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. :)
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
“App XYZ is mobile ready…” but not on Android.
Same vibe
Windows is becoming less and less of a platform every year
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.
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.
Is that the OS from the people who make Excel?
Used to be, now it's the OS from the people who operate Azure.
I remember the days when "cross-platform" meant it worked on both operating systems: Windows 95 and Windows NT!
I remember Silverlight being advertised as a cross-platform solution (in small print: works on all supported Microsoft(R) Windows™ platforms!). To this day there are things written for Electron which are „cross-platform” in the sense that Windows and macOS are supported, but none of Linux or *BSD.
Thus I have some warm fuzzies when something new is cross-platform, but not on Windows. (But hey I heard WSL supports Wayland?) Even more warm fuzzies if Windows users come to whine about availability. Happy to have lived to see this turning of tables come.
I’m not a good person, I guess.
Thus I have some warm fuzzies when something new is cross-platform, but not on Windows. (But hey I heard WSL supports Wayland?) Even more warm fuzzies if Windows users come to whine about availability. Happy to have lived to see this turning of tables come.
I’m not a good person, I guess.
Missing windows still means missing most computer users and developers specifically.
WezTerm is a great terminal that IS cross platform and works well on windows (and arguably better than ghostty)
Yep. I've migrate to it as I need a terminal that is truly cross platform.
Cross platform doesn't mean your platforms. I use Ghostty on GNU/Linux and MacOS, because it truly is cross platform.
It doesn't mean his platforms, it means the top ones, so at least his and hundreds of millions of others'
Terminals are not really targeting that entire demographic, and for the one they serve probably Mac/Linux form a majority vs Windows.
This is a wild take.
Is it? I've heard of people using a non-Microsoft terminal on Windows besides git bash and cygwin probably no more often than I could count on one hand. And people don't ever use those for the terminal, but usually for GNU. On the other hand, I find it uncommon to see anyone who chooses to use a terminal regularly using the MacOS default terminal, and there is no default Linux terminal. I find it hard to imagine a world where that take is wild.
Anyone that started computing using DOS is very aware of terminals.
> I find it uncommon to see anyone who chooses to use a terminal regularly using the MacOS default terminal
If you are going to say that about windows the same could be said about macOS. In fact, I only know of one mac user within my circle that has used the non default terminal.
Anecdotally, at day job, every terminal I see on windows is riced out. The Windows terminal app video from MS probably helped with that lol.
> I find it uncommon to see anyone who chooses to use a terminal regularly using the MacOS default terminal
If you are going to say that about windows the same could be said about macOS. In fact, I only know of one mac user within my circle that has used the non default terminal.
Anecdotally, at day job, every terminal I see on windows is riced out. The Windows terminal app video from MS probably helped with that lol.
Those millions of users are not at your job, they are not programmers, and they don't use the terminal.
[deleted]
Windows is just a web browser, yes i'm serious
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...
also.. now I want to attempt to write a Ghostty frontend as a Godot extension