Relm4 VS serde-this-or-that

There is Relm (https://relm4.org/). Which is in Rust is just GTK (through it's Rust bindings) with a nice reactivity layer on top.

I’d recommend you checking out https://relm4.org if you know a little Rust. Relm4 is currently the easiest and most intuitive way to write GTK

Relm4 might make your migration easier. It has factories which make it easy to create lists (both sync and async) and recently added TypedListView as another useful abstraction over pure gtk-rs. There is a lot of potential in Rust + GTK, you just have to find idiomatic abstractions.

Did you try Relm? It's an implementation is the elm architecture (think react) on top of Gtk. Given your experience with Gtk it might suit you really well, as you can even take only parts of it and continue using bare Gtk for the rest. Give it a try!

What about relm4? Is it generally feature complete? Can one use relm4 for most things, and drop to gtk4 for the oddball task that is not supported?

https://relm4.org/

Using this example: https://github.com/Relm4/Relm4/blob/main/examples/simple.rs

What advantage would this Rust crate have over Relm4? It seems pretty similar to me, save for the property based syntax that Forte has, instead of the set_* ones used on Relm4.

If you like Rust I recommend Relm4, one of the best experiences I’ve had with a framework tbh, be sure to learn gtk-rs first.

GitHub | crates.io | Changelog

I was just working over the weekend on putting together a project, serde-this-or-that which is inspired by a blog post of a similar name, even though technically that blog post appears to discuss something slightly tangential to the matter. This project is inspired by a question posted on SO, which suggested a crate might be useful to deserialize cases where a json field has one of multiple possible multiple types (for example it could come as str or bool). I was also working on adding benchmarks, which this is actually the first crate where I have successfully put together benchmarks using criterion which I've been kind of nervous about using in general, but based on the docs it was pretty easy to set up so I'm kind of glad about that at least.

Update: for those curious, I've added benchmarks for comparison with serde_with here. After some more testing, I've release v0.4 and am confident that performance is now on par with serde_with. Also, I noticed that whenever serde_with::PickFirst is used, performance drops; in this case, serde_this_or_that does seem to perform 12x better in such scenarios.

The full release notes can be found on the project page on GitHub as well.

I've just published an initial release of serde-this-or-that, which builts on top of serde to provide custom deserialization for fields that can be specified as multiple types.