You must log in or register to comment.
I feel like the best option at the moment is egui. It’s native. Works on the web too. Very easy to get up and running. The things I don’t like about it:
- I personally think the default style could do with improvement. Mainly it’s way too cramped. There’s a happy middle ground between no padding and bootstrap. I mean Win32/Qt/etc. got this basically right.
- Immediate mode. Yeah it’s easier, especially with Rust, but … it’s surely not how it’s supposed to work.
- The low level drawing API (like if you’re making custom widgets) is surprisingly amateur. Not something I’d want to target if I’m spending a lot of time e.g. writing a custom map widget or git graph or something.
I also tried Slint. Like the author I think the license is pretty reasonable. But it is pretty involved to set up a project and since it compiles everything from source it can take a very long time for a clean build of hello world. It’s like if you were using Qt but instead of a binary package the sources are just included in your app.
Also I have bad experiences from QML (Javascript 🤮, weird scoping rules, etc.) but hopefully they learnt from their experience.
Looking forward to the 2030 edition anyway!
I really hope iced.rs gets better on accessibility, because i really enjoyed trying it :)
Interesting read though it’s mostly a comparison on how well windows accessibility tools work on each gui framework.
Good.
Too many libraries/frameworks/products don’t factor in accessibility from the start.
Along the same vein, too many open source projects don’t factor in non-“gnu/linux” environments from the start.
It’s a lot harder to tack on after the fact rather than just having it be a part of the base design from the beginning.
Making these front and centre in a survey should be a be a bit of a wakeup for people who don’t consider what doesn’t run on their machines.
Along the same vein, too many open source projects don’t factor in non-“gnu/linux” environments from the start.
No one is entitled to anything from open-source projects.
I spent time making sure one of my public tools was cross platform once. This was pre-Rust (a C project), and before CI runners were commonly available.
I did manage it with relative ease, but Mac/mac (what is it now?) without hardware or VMware wasn’t fun (or even supported/allowed). Windows was a space hog and it’s a shit non-POSIX OS created by shits anyway, and Cygwin/MSYS wouldn’t have cut it for multiple reasons including performance. The three major BSDs, however, were very easy (I had prior experience with FreeBSD, but it would have been easy in any case).
People seem to have forgotten that doing open-source was supposed to be fun first and for most. Or rather, the new generation seems to never have gotten that memo.
POSIX is usually where a good balance between fun and public service is struck. Whether Mac/mac is included depends on the project, AND the developers involved. With CLI tools, supporting Mac/mac is often easy, especially nowadays with CI runners. With GUIs, it’s more complicated/situational.
Windows support should always be seen as charity, not an obligation, for all projects where it’s not the primary target platform.
🤡 uses windows 🤡
I thought you were joking, but this dude seriously uses windows for development. No wonder he’s running into so many issues. I can’t imagine a big chunk of rust developers using that terrible OS.
Edit: I’m surprised at the number of things he tried though and how many worked.
It’s a GUI framework evaluation. I would imagine most users of a desktop application with a GUI would be Windows users. It would generally be a little weird to develop a professional product that does not work on Windows (or at least Mac). It’s a lot easier to develop that natively than to cross-compile.
There’s a difference between a framework that builds to an exe and one that can develop in windows
I’ll be honest, I’m not really sure what you’re trying to say, but it sounds like cross-compilation to me? The article mentions several different GUI libraries that require dynamic linking and complicated build scripts, so even if you setup rustc to cross-compile (which isn’t that hard but is an extra unnecessary step for your run-of-the-mill dev who just wants to get paid), getting the build scripts to cross-compile C++ libraries or testing the cross-compiled binaries with dynamically linked libraries is a pain, assuming your build scripts even let you do that.
All of this is avoidable by building from Windows. Or I guess you can not target Windows. That works too, but most businesses won’t see that as an option.
