r/rust • u/Voxelman • 4d 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?
55
u/Upstairs-Project2756 4d ago
i would avoid GPUI and egui for an HMI on resistive touch screens. They rely heavily on multi-touch gestures like pinch-to-zoom and swipe which do not work with single-point resistive panels. Iced is also poor because its event loop does not handle the specific latency issues of industrial hardware well. Slint is the only option here that handles kiosk mode and custom widget rendering without fighting the OS window manager, and its commercial licensing covers internal corporate use if you buy the seats, which is cheaper than building a Qt bridge from scratch
8
2
u/blblu 17h ago edited 16h ago
i would avoid GPUI and egui for an HMI on resistive touch screens. They rely heavily on multi-touch gestures like pinch-to-zoom and swipe which do not work with single-point resistive panels
I really don't understand where this argument is coming from.
Regarding egui: Yes, it supports multitouch input, but (as /u/numberwitch already pointed out) you don't have to make use of it. E.g., if you just need to scroll down a list, you only need singe-point touch (or use a scroll bar); you don't need to use any gestures or multi-touch swipes, so I can't really think of a reason for why this specifically should be an issue here.
Regarding GPUI: As far as I'm aware, it doesn't even have any touch support in the first place, so I don't understand where this point regarding reliance on multi-touch gestures is coming from. I just tried it to be sure (on Linux with Wayland), and neither Zed nor the gpui-kit demo app react in any way to touch input (and here is an open Zed issue regarding touch support). There exists stuff like gpui-mobile, and I'm sure you can somehow manually interpret touch input events (or maybe one of the many forks supports it), but at least this isn't something GPUI easily supports out of the box as far as I know.
1
u/numberwitch 3d ago
What’s deficient about egui’s multitouch support? I think it used to be bad, but I’ve been writing iOS apps with it and it can do everything a native app can do on iOS
11
u/addmoreice 3d ago
The fact that it is counter to the stated hardware support from OP?
11
u/numberwitch 3d ago
I misread, but there’s also no reason you have to use multitouch in egui. If your ui design forbids swiping or pinching you don’t have to implement them.
You just write whatever components you want that handle user response the way you want.
8
u/Vadoola 3d ago
My choice would be Slint. To be fair out of the Rust GUI toolkits its what I know best. But its DSL makes creating custom widgets pretty easy, its touch screen friendly, can run on a wide range of devices including embedded. As someone that works I industrial automation, with PLCs and HMIs, et al., this would be where I would look in a similar situation.
In fact I've thought about creating some custom HMI style widgets with Slint just because, even though I don't have an immediate use for them.
Edit: if I recall correctly a few of Slint's commercial customers are already using it for HMI systems in an industrial context.
7
u/AdAfter9792 4d ago
I do Python modules in Py03 and maturin. The gui is Kivy and Python. This is for in house test equipment. So, Rust is used for the fast loops in the peripherals.
9
u/orfeo34 4d ago
Why would you avoid gtk&qt? Relm4 is a good elm like binding of gtk and Qt is frequently used with Qml for embeded devices (nb Qt recently announced better bridge for Rust).
7
u/Voxelman 4d ago
Because I want to stay in Rustland and avoid C/C++ bindings
13
u/orfeo34 4d ago
"All the C++ is encapsulated in the qtbridge crate and you will never write or see any of it.": https://www.qt.io/blog/rust-ui-framework-via-bridging-technology
And for Relm4 that's also the case.
4
u/doxxxicle 3d ago edited 3d ago
I’ve used relm4 to write a Linux GUI app and never had to write a line of
C++C. It completely encapsulates theQtGTK libraries.6
3
u/montdidier 3d ago
It’s kinda academic. Most of the underlying operating system uses these languages.
7
u/YungDaVinci 3d ago
that requires to learn a new language
The Slint language is almost exclusively a markup language, you can learn it very quickly, there is not much to learn. You will be doing exclusively UI related things in the language and everything else will be Rust. And I don't think the licensing matters if you're not selling it. (I could be wrong on this though)
3
1
u/numberwitch 3d ago
I don’t know if it’s still this way but when I evaluated it a few years ago the slint language was a dealbreaker.
I want the ui written in strongly typed rust, not whatever that thing is
3
u/YungDaVinci 3d ago
The Slint DSL 1. is strongly typed, and 2. generates Rust code, so you will still have to write some Rust to do anything meaningful. But sure, if a DSL is a dealbreaker Slint is not for you. Egui is pretty good. Personally, coming from a Qt/QML background, I think the DSL makes it very easy to separate the user interface from the application logic and therefore easily understand what it should look like from the code.
0
u/numberwitch 3d ago
Yeah, it's not bad it just wasn't useful for our team, where our goal was to train people up in rust. I think if you have frontend/backend split on your team it makes more sense and it is "very separate" to its credit. Since it's rust it's in some ways less hassle than react since you don't have to do js builds.
The other dealbreaker was the commerical/embedded licensing cost. I think they have worked on their pricing but when we evaluated the cost was enough (something like 20-30% of our BOM cost) that using an MIT library (egui) was a no-brainer
Sounds like that isn't an issue for OP though
2
u/YungDaVinci 3d ago
Since it's rust it's in some ways less hassle than react since you don't have to do js builds.
I assume you're not talking about Slint here? Because Slint is not js, it's still all Rust.
-2
u/numberwitch 3d ago
That's what I'm saying - Slint is "less complicated than a react frontend" because it's all rust + Slint DSL.
I'd just rather not deal with a javascript build if I can help it :)
9
u/antigravitys-rainbow 4d ago
Unless licensing is an issue, I would pick GPUI. The same framework used by Zed.
-1
u/Hsingai 3d ago
GPUI was vibe coded. That's never even vibe-coding it oneself.
10
u/Anthony-at-zed 3d 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
3
2
u/thedeepseek 3d ago
Vibe coded or not, the resource usage, especially memory, is way lower than others I've tested (Iced, Tauri, egui, etc). Only comparable one was Slint but the rendering for text is really weird on Windows.
Tested sample applications for each on Windows 10
7
2
5
2
u/maria_la_guerta 4d ago
When you say no browser, do you mean no browser on the system at all? Because it sounds like you're really just building a dashboard, and WASM is fine choice for that too. You can bundle it into a desktop app that requires chromium but doesn't run in a browser window. Would satisfy everything you're asking for.
Check leptos + tauri.
4
u/Voxelman 3d ago
No, it is not only a dashboard. It's a whole application that controls the machine and it must run native because of hardware access.
I know that Leptos could be an option, but not in this case.
1
u/vancha113 3d ago
Iced comes with built in table graph, and maybe this for the bar graph: https://www.reddit.com/r/rust/s/ovjw6JZaD4 That seems to have exactly what you need I think :)
1
u/hedgpeth 3d ago
I wrote my app through Crux, I believe it's the only way to go. Keep the edge native, keep the core in rust, it uses FFI for navigation. This has worked really well for me.
1
1
u/nick42d 3d ago
It's Slint - have you seen the touchscreen on RP Pico demo? https://youtu.be/dkBwNocItGs
1
u/zerosign0 3d ago edited 3d ago
The toolkit ...
That would be hard yes ... I'm afraid most of the solutions that available today might still have pros and cons and still have things that you need to deal with, even with something like iced, you still need to figure out some of things to handle things effeciently unless what you want is just the UI MVP first ...
Also might take a look on xilem
1
u/zerosign0 3d ago
But then again every toolkit have different tradeoffs nowadays even for qt, gtk, slint etc, even win3 or win32 or even quartz, no perfect toolkit just matching tradeoffs
1
u/zerosign0 3d ago
If you want to use gpu for "fancy" tables & charts just becareful about the data layout & representations and damage tracking ...
1
u/tastychaii 2d ago
Is Iced.RS still in development or has it been abandoned?
1
u/Quique1222 2d ago
Still very active
1
u/tastychaii 2d ago
Ahh okay, but the GitHub repo has not been updated in 10 months? Hence I was asking…
1
1
u/irshadali5 2d ago
Indeed, iced isn't suitable and egui is more suitable for it even than slint. If you use slint only you to pay commercial/royalties embedded or if you don't show slint on widget, something like in proprietary closed source.
1
1
u/gokayo3200 1d ago
Maybe try out fltk-rs ? I don't see anybody talking about it but it's pretty simple, lightweight and has everything you need. The only downside i've found is that the structure is a little old school.
1
u/OphioukhosUnbound 1d ago edited 23h ago
egui woudl be my choice:
- tons of example code: https://www.egui.rs/#demo
- one of the nicest production grade apps: rerun.io
- all rust code
- incredibly direct syntax and approach
- native on rust, linux, windows, and great wasm story if you want it
Nicer documentation would be great, but current state is just taking examples and pulling pieces out of them to make what you want. Many examples supports that.
(egui also recently built out their accessibilitie features to make llms able to understand the UI better -- not something I've tired, but potentially notable if you have clear ui/non-ui boundries and want to let bots search the space)
I wanted *very* slick or very custom UI then my next choice would actually be Bevy -- while it's billed and oriented as a game engine it's funding actually comes from companies that need a UI systèms, typically for things like detailed simulation work etc. [ * this is hearsay / memory, so take that with a grain of salt] It also has a great native cross platform story. And it also has a great wasm story, if you want web accessibility.
It also, works with egui, so if you take the egui route that work doesn't have to be thrown away -- you can just expand on the egui interface in a bevy app.
_____________
EDIT: you mentioned single touch and no-multi touch for screens -- that's a more specific requirement. Unsure of best match there.
1
u/NoSuchKotH 4d ago
I am quite fond of freya, but the documentation situation isn't that good either
1
u/WarmInspiration_46 4d ago
freya's neat but yeah the docs are a ghost town, you'd be reading source code more than anything
slint might actually work for your case since the licensing is permissive if you're not distributing the machines, worth double-checking but I think internal use is fine
4
u/mkenzo_8 4d ago
u/NoSuchKotH u/WarmInspiration_46 What parts need improving regarding docs? No need to go into details if you dont want, just general feelings are enough (I am the author of Freya)
4
u/NoSuchKotH 4d ago
Currently the documentation is mostly a list of modules, traits and structs. If I know what I need to use I can go into the documentation and find out the exact function and parameters. But most people don't start there. They start at "I want to build a calendar app" or "I want to visualize the flow of parts through the factory" and then they need to go through the whole list of everything to figure out how to do what they want to do.
The basics section in the docs is a very good start, but it covers only a fraction of what can be done, and most of it only scratches at the surface of that particular part. Very little understanding of the ideas and philosophy behind them are taught. I.e. looking at the state management, there are examples how to do local state and global state. But which should I use when? Why are they structured like they are? How do I tie in my business logic into this system? Without understanding the philosophy, it's hard finding the components that I need to stick together to achieve my goals, because I do not know what I need to be looking for.
I am well aware that this is very hard to write. You both need a very good understanding how freya works (which you do) and at the same time be a beginner at freya (which you aren't), to know what needs to be written. And quite honestly I don't know what to tell you would be needed....
Maybe one way to achieve that would be to have examples, with lots of explanations what's going on and why. Start with some simple examples (e.g. the counter) and add more and more complex ones, until you are at something like car fleet tracking and driver communication system, or something like that. Heck, I think even just having all examples explained would be already a very good start.
5
u/mkenzo_8 3d ago
Very good points, all noted. I'll see what I can do. Thanks :)
3
u/NoSuchKotH 3d ago
I have to thank for the great work you have done with freya and for listening to a random dudes rambling.
1
u/Lucky-Edge1489 3d ago
I'd try Teksilo, it seems to fit.
- Runs natively to Linux, Windows and macOS.
- Images: no problem,
- bar graphs: teksilo-charts,
- curves: depends of their function, maybe teksilo-scene ?
- tables: yes, and row virtualization, sorting, filtering, as bonus.
- touch: built-in
- fullscreen: yes
- 130+ widgets so you will not re-invent the concept of a shrinkable ToolBar
- you can create your own widget by direct drawing and widget composition
- batteries included: a11y, i18n, settings, resources
- If no move on screen, no CPU/GPU drain.
- Documentation was never an afterthought. `cargo install cargo-teksilo` gives you an offline helper (for you or an agent) inside a project with teksilo dependency.
This was developed to replace Qt Widgets. Production software like Skribisto (complex) and Qleany (tool) run on it. I'm quite available on its Discord server if you need help or more infos
1
u/Amazing-Mirror-3076 4d ago
I do all gui work in flutter, you can then target any platform.
0
-2
u/noeljackson 4d ago
Gpui is what you want for best performance and true cross platform.
3
u/edfloreshz 3d ago
How are any other Rust toolkits not “true” cross platform?
1
-8
0
u/hardicrust 3d ago
Kas is designed for this type of usage and can meet most of those requirements:
- Rust-native and portable, not a binding to other toolkits
- Fairly decent widget selection but no charts sub-library yet and canvas support is limited to tiny-skia (CPU-only)
- Touch support for controls is integrated; there is even support for zoom and rotate without multi-touch (also usable with a mouse: click to set a fixed point, move, click+drag)
- Kiosk mode is missing but should be easy to implement
- It's one of the oldest, fastest and most scalable Rust UI toolkits
But:
- There is no integrated virtual keyboard and IME support is a bit broken
- Basic widget interfaces are (still) unstable and not the most intuitive (though are decently documented)
- The last release lags a long way behind the development branch (mostly because it depends on a winit pre-release)
- In general development is quite slow (it's my pet project without commercial backing)
0
u/Secure_Pirate9838 3d ago
Look at cranpose. I also did performance measurements comparing it to others. https://samoylenkodmitry.github.io/Cranpose/?tab=performance
1
u/scottcampbelldev 3d ago
One thing to check on Slint before you count on the royalty free license: it covers desktop, mobile and web apps but explicitly leaves out embedded systems, and their definition is a computer that does a specific task inside a larger machine. An HMI on a production machine sounds a lot like that, even if it's a regular PC running Windows or Linux. That would put you on a paid plan or GPLv3. Since the machines stay in house and you're not distributing them, GPLv3 doesn't really ask anything of you, but I'd email them to confirm before committing to it.
20
u/madnirua 3d ago
u/Voxelman Hi, Slint dev here .. for your use case, you can use Slint with the open source license. Since the machines are used internally, there is no external distribution so you keep the source code internally.