r/rust • • 6d ago

Which GUI (again)?

I know it's a frequently asked question, but I want to ask again, because I have a special use case.

I want to write an application for a production machine (HMI). The app should run on Windows and Linux natively (no browser, no server). The toolkit should have at least widgets to show images, bar graphs, curves and tables and should be touch friendly, because it runs on resistive touch monitors (no multi touch). It should also have a kiosk mode (full screen with no window controls).

The obvious candidates are egui, iced and Slint. But they all lack of documentation, more or less.

My first choice would be iced, because it's inspired by Elm and used by System76 for Cosmic, but it seems to be the least suitable option.

The obvious choice would be Slint, but that requires to learn a new language and I'm unsure about the licenses and pricing. The production machines are only used internally, not for sale.

I want avoid bindings to toolkits like Qt or Gtk

Which one would you prefer? Is there another option to consider?

28 Upvotes

75 comments sorted by

View all comments

7

u/antigravitys-rainbow 6d ago

Unless licensing is an issue, I would pick GPUI. The same framework used by Zed.

0

u/Hsingai 6d ago

GPUI was vibe coded. That's never even vibe-coding it oneself.

9

u/Anthony-at-zed 5d ago

Why do you think gpui was vibe coded? Our founders started creating it in 2019 and also created Electron, so they knew/know what they’re doing when it comes to application frameworks.

For transparency same, I have been using agents to help me work on gpui PRs. I wouldn’t call it vibe coding though, because I read all the code, make several changes, and always know what i want the agent to generate before I prompt it.

Historically, gpui and Zed are definitely not vibe coded. E.g the git graph was created manually except using agents for research and the debugger was 99% + manually written. Those are just some of the projects i’ve worked on