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.
I haven’t used Haskell much. I thought to try it with agentic help, but then read this post that its compilation times might make it unviable. But what’s your experience?
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.
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!
You also won't have accessibility on Windows either unless you can somehow get it to enable accesskit integration. (I really don't get the open source norm that something like accessibility should be opt-in, particularly with UI toolkits and the like, but eh.)
AFAIK, the OS-specific Qt themes don't wrap the native widgets, it reimplements them. They are rather thorough though, making sure their OS-specific theme matches the look and behavior of the native OS, which makes it one of the best framework to do something that feels close to native.
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.
Not sure what the dev intended, but the title and page imply that writing the app is idiomatic, not that the app itself is idiomatic (to the host platform)
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.
I think the main idea here is the "being able to use Rust for x-platform UIs". If any language is acceptable, yes, you cold use Dart (Flutter), Delphi (Lazarus), C++ (Qt), etc.
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 think the main idea here is the "being able to use Rust for x-platform UIs".
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.
are you hinting at Elm? sorry my friend, that aint spagetti to me.
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).
Sure. But you're stuck with GTK on every platform. "Cross platform, so long as you want to use GTK everywhere" is much less exciting than using actual native cross-platform UI elements.
You have to head to the documentation to see an example. It is still Rust, which is a bit of an acquired taste so keeping that beauty off the main page makes sense.
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
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.
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...
Theoretically probably yes, but practically... I've spend whole weekend to try to force wxWidgets (gtk-based) to compile without X11 support (wayland only). The amount of problems with glib+gtk I've encountered on Linux forced me to go outside and doubt in my ability to think like a programmer. And gtk and glib are both Linux-first projects.
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.
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.
Is your Haskell solution open source?
No, it is a commercial project. But there are others following the same pattern on the haskell OSS side. Check
https://github.com/Kleidukos/ghcup-gtk/blob/d384e89dd48b4065...
for an example. That program is a UI for the standard haskell installer.
I haven’t used Haskell much. I thought to try it with agentic help, but then read this post that its compilation times might make it unviable. But what’s your experience?
I mean it is compiled language, but it is fine IMHO. I use `ghcide` which is a script for `ghci` (the repl) if an agent wants access.
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.
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!
You also won't have accessibility on Windows either unless you can somehow get it to enable accesskit integration. (I really don't get the open source norm that something like accessibility should be opt-in, particularly with UI toolkits and the like, but eh.)
How many proper cross-platform approaches are there these days? Just about every one I've seen is "grab the native platform's canvas, draw your own".
- Grab the native canvas, draw your own UI
- 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/
Doesn't Qt wrap native UI toolkits? It looks very native...
AFAIK, the OS-specific Qt themes don't wrap the native widgets, it reimplements them. They are rather thorough though, making sure their OS-specific theme matches the look and behavior of the native OS, which makes it one of the best framework to do something that feels close to native.
ok. did not know that.
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.
Not sure what the dev intended, but the title and page imply that writing the app is idiomatic, not that the app itself is idiomatic (to the host platform)
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.
I think the main idea here is the "being able to use Rust for x-platform UIs". If any language is acceptable, yes, you cold use Dart (Flutter), Delphi (Lazarus), C++ (Qt), etc.
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 think the main idea here is the "being able to use Rust for x-platform UIs".
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.
are you hinting at Elm? sorry my friend, that aint spagetti to me.
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).
> Built on GTK, Relm4 runs on bare metal with no additional runtime in between.
So, not native in the sense of using or even resembling the native UI toolkit.
unless, of course, your native UI toolkit _is_ GTK
Sure. But you're stuck with GTK on every platform. "Cross platform, so long as you want to use GTK everywhere" is much less exciting than using actual native cross-platform UI elements.
Why no examples of how "beautiful" this library is?
You have to head to the documentation to see an example. It is still Rust, which is a bit of an acquired taste so keeping that beauty off the main page makes sense.
I got a 404 when heading to the examples.
Because it’s GTK4 and it’s expected that you know what that is if you’re using this.
And if you're unfamiliar, there's widget galleries for GTK4 and Libadwaita both:
https://docs.gtk.org/gtk4/visual_index.html
https://gnome.pages.gitlab.gnome.org/libadwaita/doc/main/wid...
What do you mean, there's a screenshot link right there in the docs: https://docs.rs/crate/relm4/assets/screenshots /s
> Truly native
> 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".
GTK has "native" backends for linux (wayland/x11), but also win32 (windows), quartz (macos), and web. Plus there is an experimental backend for Android
https://en.wikipedia.org/wiki/GTK#/media/File:GDK_software_a...
some theoretical thoughts along similar lines, but both Qt & Gnome.
https://docs.google.com/document/d/15jnIEIfvBu87tn688-lhwcSi...
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.
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...
Theoretically probably yes, but practically... I've spend whole weekend to try to force wxWidgets (gtk-based) to compile without X11 support (wayland only). The amount of problems with glib+gtk I've encountered on Linux forced me to go outside and doubt in my ability to think like a programmer. And gtk and glib are both Linux-first projects.
(I failed to achieve that Wayland-only build btw)
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.
I had to read the comments to figure out whether this was AI or not. I guess that's a sign of the times...