141–150 of 228 posts
Earlier quoted context omitted.
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'
Earlier 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…
> 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.
Earlier quoted context omitted.
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,…
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.
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 refer…
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.
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.
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.
Earlier quoted context omitted.
Aren't GTK and Qt (community edition) both LGPL (though different versions)? 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.
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.
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.
Earlier 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…
> 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.
> 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 wo…
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'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.