@ngompa I understand what you mean. I have no experience with Qt, except for trying it once when it either didn’t work or looked bad. I bet it was a skill issue, but I haven’t tried it since.
The primary reason is that I am already familiar with the iced GUI toolkit. I learned the basics of Rust Iced in my free time, and using libcosmic feels like a more mature option.(libcosmic is build on iced)
Benefits
I have no issues with cross-platform portability out of the box. Plus, I don’t need to deal with a massive Qt dependency tree.
Negatives
It is not as optimized yet and still has some rough edges. Incomplete features like animations require a lot of work, which I took the time to implement myself (they will be made better in the upcoming release updates).
The Rust Problem
Whenever I build a new, complex application, I choose Rust every time. C and C++ are inherently memory-unsafe, and I simply dislike C++.
However, the problem with Rust graphics frameworks is that those using inter-language bindings are a pain to work with. I previously experimented with GTK4 Rust bindings for an app that never shipped, the GNOME documentation really needs to improve, and the lack of clear guidance forced me to drop the project. There was too much boilerplate, and Rust’s safety guarantees often went out the window.
Instead, I prefer pure Rust alternatives—the best options for desktop GUIs being Iced and Slint. Slint is similar to Qt (made by former Qt developers), production-ready, highly mature, and features a QML-like style. I chose Rust Iced because that is what libcosmic is mostly built on, and it offers much better theming and integration with the Linux desktop.
Rust Iced builds the UI directly in Rust code, allowing the compiler to check it. While this is a lot of work, it eliminates many bugs before they can happen. State mutation is strictly separated from the UI and can only be modified via messages, which are native enums in Rust.
I really like Rust Iced from an architectural standpoint. It builds into a single application of a reasonable size and works across all three major operating systems. Because it has commercial backing, it should have a solid future.
Alternative Approach
If libcosmic really cannot be used, I can rebuild the UI in Slint. I will not write Qt bindings myself, but someone else is welcome to do so. I have written the Rust backend to be completely abstracted, meaning another developer can just hook into it and only needs to write the UI layer.
Question
Fedora has a COSMIC spin, which I currently use. There must be a packaging infrastructure for it already, or am I wrong? I could maintain the project binaries myself, but I have no idea how to go about doing that yet.
Performance
The app can be compressed down to 5.9 MB using upx --lzma --best /target/release/new-writer. For comparison, the Fedora Media Writer (an animated Qt application) is 2.1 MB on my Fedora 44 stable system. The new gui advanced i expect that the binary size will double or triple the binary size, a Qt GUI is inherently heavier than what I have now. I find the compressed size really good and don’t think a Qt version could beat it.
At idle, my application uses 20 MB less memory. During a workload like flashing an image, my application uses 70 MB less memory than the native media writer.
Funny
I tested this using the UPX-compressed version. Funnily enough, the UPX version used 1 MB less memory than the uncompressed one—I have no idea why. Ultimately, the memory overhead with or without UPX is nearly identical and not really noticeable.
) 
- this looks super amazing!
