What’s new in relm 0.10.0?

Relm is an attempt to do an idiomatic GUI library in Rust, based on gtk+ and tokio. See the introduction article for details about why this library was created and how to use it.

This new release is huge: a lot of changes happened under the hood, the API was changed and features that were unsound were removed. The web browser titanium has been updated to use this latest version of relm. The journey has not been without pitfalls and some convenient features of relm were removed because they caused issues.

Removed features

Shared model

The model is no longer a shared. In the previous versions of relm, it was a Rc<RefCell<Model>> for convenience: it was possible to share a model with a gtk+ callback for instance. However, when developing titanium, I’ve again got bitten by the infamous borrow mut error at runtime, while this was precisely one issue relm tries to solve. Now, there’s a single owner to a widget’s model and the only way to mutate the model is through its widget: if we want to update the model from another widget, we need to send a message to the other widget.

Synchronous callbacks

Also, the feature allowing to use synchronous callbacks in an asynchronous way were removed because they do not fit well within the model of relm, where everything is asynchronous. While this feature was convenient because it allowed to return a value to a gtk+ callback from within a widget’s update method, it was removed because it could cause slowdown if abused and mainly because it was unsound. Remember that the update method takes self by mutable reference, and with this feature, it was possible to block an event handling, while it was waiting for the widget to resolve the value to be returned to the gtk+ callback. So, if the event was triggered twice, it could be possible to have two &mut over the model. That’s a pretty bad thing that Rust prevents us from doing.

Networking examples

This release took a long time to be release. The reason is that I was waiting for tokio issues to be fixed. Since I’ve been waiting for months and they are still not resolved, I decided to release a version without the examples relying on tokio (the http and websockets examples). And they’re not likely to be fixed soon since tokio-proto is likely to be de-emphasize and it’s used both by hyper and twist (the websockets crate). That doesn’t mean it’s not possible to use tokio: titanium uses tokio, but it needs a special version of the tokio-based crate so that the futures can be spawned on the glib event loop. In order to be able to use tokio-based crates with relm, they need to be updated to use the new Executor trait instead of relying on the tokio-core Handle.

Switch to futures-glib

During the Rust+GNOME HackFest in Mexico, Alex Crichton and I worked on a way to spawn futures directly on the glib event loop: the futures-glib crate. Using that, relm now executes only in one thread, which simplify a lot of things while being more efficient.

Is relm usable on stable Rust?

Yes, it is! And you can even benefit from the nice syntax by using the relm_widget! macro.

Projects using relm

There’s already a few projects using relm. If you use relm, consider posting the link to your project in this issue.

New features

Here’s other new features of this release, in bulk:

Need help?

If you need help to use relm, there’s a gitter and I’m also usually on #gtk-rs, #rust-fr and the GNOME’s #rust channel. You may also open an issue on GitHub to ask questions.

Future

Beside many issues to be fixed and corner cases of gtk+ to support in relm, the most important thing to improve is the error messages. Since relm heavily uses code generation, the error message are very bad. Relm needs to be updated to use the proc-macro2 crate in order to be able to keep the position of the tokens in the generated code. This will require a huge refactor because many things changed in the syn crate.

Comment on reddit.

Previous
Next