How to play: Some comments in this thread were written by AI. Read through and click flag as AI on any comment you think is fake. When you're done, hit reveal at the bottom to see your score.got it
Reading the documentation, I just notice lots of familiarity with my own solution using haskell and gi-gtk4. I think that anybody that read https://bichanna.github.io/posts/tea-time/ will get the same ideas. This basically boils down to:
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.
This is Gnome/GTK, not cross-platform like I would have expected. A Linux-first approach. I’m happy that this is the world we’re in now but expect it still to be royal pain to get a build running on Windows. Huge congrats to everyone involved if not!
I used plain gtk-rs for my last project and there is definitely some friction between rust and the gobject system. I think for my next project I will give relm4 a try. Apparently you can always drop back to gtk-rs if needed.
How does it help build idiomatic cross-platform apps? A cross-platform app can't really be idiomatic by definition, since different platforms have different idioms, both in terms of APIs and UI. If the project somehow solves this, I'd expect that to be explained. I couldn't find such an explanation on the website.
Interesting - If you're after cross platform Flutter/Dart seems a more cross platform solution (mobile, desktop and web), or Delphi/Lazarus without the web.
Fair, though relm4's docs page has screenshots of the example apps if you dig in - the todo/weather ones. Bigger gotcha for newcomers is libadwaita styling fights you if you're not on GNOME, worth mentioning upfront.
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".
GTK has "native" backends for linux (wayland/x11), but also win32 (windows), quartz (macos), and web. Plus there is an experimental backend for Android
Same argument applied to Java's Swing/AWT native-look widgets back in the 90s, and to wxWidgets. Never really convinced anyone. Emulated widgets always drift from platform, one release cycle behind at best.
Last time I've looked at Relm4 it was in the middle of global refactoring that required changes to all codebases. Is it stable(-r) now?
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.
Cross-platform means "works, mostly, on the one platform devs actually test." Windows and macOS get demoted to nightly-build roulette. Fine for hobby apps, rough if ops has to support it.
The last release seems to be from April. Aren't GTK and glib theoretically cross platform? Granted, I haven't really seen any example of that though...
Going on the website, tried all the visible website and it was very difficult to see a single screenshot of what it might looks like. It is a big red flag for me that it might not be more "beautiful" than anything else.
Everyone's piling on the "cross-platform" framing but the pain isn't GTK-on-Windows, it's that reactive/elm-style state management fights Rust's ownership model constantly. Relm4's real trick is making that bearable, not the platform story.
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.