this post was submitted on 14 Apr 2025
35 points (88.9% liked)

Rust

6800 readers
18 users here now

Welcome to the Rust community! This is a place to discuss about the Rust programming language.

Wormhole

!performance@programming.dev

Credits

  • The icon is a modified version of the official rust logo (changing the colors to a gradient and black background)

founded 2 years ago
MODERATORS
top 25 comments
sorted by: hot top controversial new old

I really hope iced.rs gets better on accessibility, because i really enjoyed trying it :)

[–] FizzyOrange@programming.dev 7 points 3 days ago

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!

[–] daniskarma@lemmy.dbzer0.com 5 points 3 days ago (1 children)

Interesting read though it's mostly a comparison on how well windows accessibility tools work on each gui framework.

[–] spartanatreyu@programming.dev 2 points 2 days ago (1 children)

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.

[–] BB_C@programming.dev 6 points 2 days ago (1 children)

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.

[–] spartanatreyu@programming.dev 0 points 1 day ago (1 children)

No one is entitled to anything from open-source projects.

I never said anything contrary to this.

but Mac/mac (what is it now?) without hardware or VMware wasn’t fun

Letting MacOS users support MacOS hardware is generally easy when you already have BSD and/or busybox support already.

Windows support should always be seen as charity, not an obligation, for all [open source] projects where it’s not the primary target platform.

Ordinarily I'd agree, except these are GUI Libraries.

The whole point of them is to be a generic interface that prevents you from needing to use the platform specific APIs directly.

If GUI libraries aren't going to target the most widely used platforms, then why wouldn't the developer just use the platform specific APIs directly?

[–] taladar@sh.itjust.works 2 points 12 hours ago

In reality Windows isn't the most widely used platform, not where it counts, among the developers of those libraries. And finding competent Windows developers to contribute also isn't easy while finding Windows users demanding support is quite easy since the factor of developers per user is so much worse on that platform.

[–] Busyvar@jlai.lu 1 points 3 days ago

Excellent post, i already use Dioxus and is very interested to know future work on Freya.

[–] monogram -5 points 3 days ago (2 children)
[–] onlinepersona@programming.dev 10 points 3 days ago* (last edited 3 days ago) (1 children)

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.

Anti Commercial-AI license

[–] TehPers@beehaw.org 5 points 3 days ago (1 children)

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.

[–] monogram 0 points 3 days ago (1 children)

There’s a difference between a framework that builds to an exe and one that can develop in windows

[–] TehPers@beehaw.org 4 points 3 days ago (2 children)

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.

[–] bunitor@lemmy.eco.br 1 points 3 days ago* (last edited 3 days ago)

as someone who used to develop a cross-platform (linux and windows) desktop application: the bulk of development took place on linux. i only ever booted to windows to build the app and make windows-exclusive adjustments, but never to actually develop any features

[–] monogram 0 points 3 days ago

My past experience in desktop apps have been Flutter and Wails and have always cross compiled to an exe.

The less I need to touch windows the better.

[–] FizzyOrange@programming.dev 0 points 3 days ago (1 children)

Windows is fine. Get off your high horse.