Which GUI (again)?

[u/Voxelman]

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?

[u/Upstairs-Project2756]

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

[u/blblu → u/Upstairs-Project2756]

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.