61–70 of 228 posts
Earlier quoted context omitted.
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.
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…
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.
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. :)
I haven't worked with GTK, but what you are describing here sounds reminiscent of what we have been dealing with trying to build Godot bindings in Zig with a nice API. the project is in mid-flight, but Godot: - has tons of OOP concepts: classes, virtual methods, properties, signals, etc - a C API to work with all of those concepts, define your own objects, properties, and so on - manages the lifetimes of any engine o…
Earlier quoted context omitted.
> 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 m…
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 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.
> 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…
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/57…
I haven't worked with GTK, but what you are describing here sounds reminiscent of what we have been dealing with trying to build Godot bindings in Zig with a nice API. the project is in mid-flight, but Godot: - has tons of OOP concepts: classes, virtual methods, properties, signals, etc - a C API to work with all of those concepts, define your own objects, properties, and so on - manages the lifetimes of any engine o…
Earlier 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.
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 wh…
> 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.
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).