1. Use a native widget system such as GTK (I evaluated Qt too)
2. Wrap widgets into a component datatype that is aware on how to update the widget when the props/model changes.
3. Define a dispatch closure that is passed to widget that accepts messages. Actions on the widgets should use this instead of mutating a reference.
4. That dispatch closure is component aware and it will call the update function on all the widgets.
There are some extra complications for long running computations but the model is a good base to build on. I wish the best to the relm team, most likely I will use them when programminmg in rust.
https://github.com/Kleidukos/ghcup-gtk/blob/d384e89dd48b4065...
for an example. That program is a UI for the standard haskell installer.
- Electron and friends (web toolkits, tauri, etc)
- Or my favorite: Just have a UI library which wraps all the native UI toolkits on each platform. Eg: https://daybrite.dev/
You can sometimes tell the difference because the QT emulated widget can do things that the native widget can't.
There are bridges to Rust:
https://pub.dev/packages/flutter_rust_bridge
https://github.com/qt/qtbridge-rust
And this project, Relm4, is one of m.
I had to click a little to confirm that Relm4 (like the original Relm) is --as the name shows-- borrows from https://elm-lang.org
Elm comes with some really cool concepts known as The Elm Architecture (TEA) and many projects have since borrowed from it. Usually people in the FP-enthousiasts group are more inclined to like TEA. I'm not sure to what extend the brides mentioned above allow for a TEA-like architecture.
I was okay with using C as the logic layer and Lazarus as the GUI. No reason you can't do that with Rust, but it will limit the amount of spaghetti-ish patterns that you may want to create.
it's a lot of fun working at a codebase that does essentially does not allow for runtime programming errors (validation errors are still there, or API/3rd-party errors still need to pass through your code; your Elm code is essentially incapable of creating any runtime programming errors of it's own).
GUIs are hard, regardless of tech stack.
So, not native in the sense of using or even resembling the native UI toolkit.
https://docs.gtk.org/gtk4/visual_index.html
https://gnome.pages.gitlab.gnome.org/libadwaita/doc/main/wid...
> Built on GTK[...]
If it's built on GTK, it's not "truly native" on anything but Linux (and with the lack of accessibility to boot). If you're not crafting your own NSButtons and such, you are nowhere near "truly native".
https://en.wikipedia.org/wiki/GTK#/media/File:GDK_software_a...
https://docs.google.com/document/d/15jnIEIfvBu87tn688-lhwcSi...
Also what is this cross-platform you speak of, if we're talking about Gtk4? Compiling glib on Windows doesn't sound very cross-platform to me. Heck, Gtk4 doesn't sound very cross-platform if we're thinking about anything that's not Gnome.
(I failed to achieve that Wayland-only build btw)