“Ghostty is cross platform…” but not on windows :D “App XYZ is mobile ready…” but not on Android. Same vibe
WezTerm is a great terminal that IS cross platform and works well on windows (and arguably better than ghostty)
We rewrote the Ghostty GTK application
51–60 of 228 posts
Re: We rewrote the Ghostty GTK application
#52I'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
Re: We rewrote the Ghostty GTK application
#53Earlier quoted context omitted.
> 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://gho…
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.
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...
Re: We rewrote the Ghostty GTK application
#54Earlier quoted context omitted.
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.
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
Re: We rewrote the Ghostty GTK application
#55“Ghostty is cross platform…” but not on windows :D “App XYZ is mobile ready…” but not on Android. Same vibe
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.
Re: We rewrote the Ghostty GTK application
#56Earlier quoted context omitted.
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.
Re: We rewrote the Ghostty GTK application
#57Earlier quoted context omitted.
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.
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…
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.
Re: We rewrote the Ghostty GTK application
#58Earlier quoted context omitted.
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.
> 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.
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.
Re: We rewrote the Ghostty GTK application
#59> 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 tho…
> 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://gho…
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.
Re: We rewrote the Ghostty GTK application
#60Earlier quoted context omitted.
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?
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 inco…
> 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.