Are we GUI Yet?

The state of building user interfaces in Rust.

#Rust2019 Are We GUI Yet?

The Rust 2018 journey has been great so far. 2018 was a year filled with great feature additions to the core language along with improvements to the ecosystem. The year 2018 also saw the release of the first fully fleshed out Rust edition 🎉. And as 2018 has come to its end, we are once more encouraged to Blog about the things we'd like to see in 2019.

I have many things I'd like to see in the new year and to bring it home its mostly the same thing I've read in other posts on Reddit and/or blog posts:

I will finish what you started

-- Ben Solo aka Kylo Ren

But you might have guessed this is not really what this post is about! I want to tackle one specific topic in contrast to other posts that are mostly from a different perspective, and I want to paint the "Big Picture" and overall direction. This post is about the narrow topic of GUI and I want to make a case to convince, at least a fraction of the community that is interested in this field, that it might be a good idea to invest in this direction.

Where are we now?

It is not the case that its impossible to write a GUI for your Rust application. But you really have to think about in what direction you want to go and through what hurdles you want to jump. The field is also sprinkled with many attempts that just turned out to be a dead end. Its hard for a newcomer to really get a clear vision of what is available and possible. It is also very hard for people wanting to contribute to find the projects they like to help. What I found in the last two years following the topic was that many people wanted to change the lack of a Rust GUI and started on their own without even knowing other projects existed. Some projects survived and many just died off. From the things that I have observed I would say many have simply given up because of the great amount of work involved and you can only do so much as a single person. For example some projects wanted to build bindings for Qt and others wanted to build something on top of WebRender. So I think the main goal for areweguiyet currently is to:

How can these points be achieved? I have no idea and this is up for discussion. However, 2019 is the year we can start to make a more coordinated approach towards a shared goal. We want areweguiyet to be platform for this.

To have a quick overview, I gathered together a rough list of the various approaches that are possible without being exhaustive.

Native approach

Currently the approach that yields the best results if you want to have the "most" native look and behaviour on each platform, is having Rust as either a library with FFI, or running as a separate Process in the Background doing IPC, while your frontend is programmed in one of the "main" languages of the respective toolkit. I think we can't really do much here except for having better language interoperability and crates that make use of it.

Cross Platform Toolkits

As we've seen the native approach can be quite involved, especially if you want to target multiple platforms. It is nonetheless the best way if you want to achieve the best experience on a particular platform. If your constraints are not that high and you want to save some development time, you may want to look at various cross platform toolkits:

These are currently the next best options. Rust Qt Binding Generator and qmetaobject-rs are currently the most advanced projects for Qt and the way to go if you really want to stay with Rust in the frontend and use the maturity and power of the Qt framework. Mind you, both projects are still in its early stages and I don't think mass adoption has started so I expect many problems to arise that are not obvious if you're playing with both. One Problem I had with Qt/QML bindings in the past was that for some things – like configuration of webviews QtWebView::initialize(); – you need to have some C++. Both Rust Qt Binding Generator and qmetaobject-rs handle this problem in a different way. In the first you practically just start on the C++ side and immediately jump to the Rust, so you could prepare things on the C++ side first and the second allows you to call inline C++ closures with the cpp crate here is an example

Both approaches require you to handle at least some C++ code if your projects start to get a little more complex or you want to use more advanced features of Qt.

I think from all the things we have seen so far the most "advanced" Project in terms of usability is Gtk-rs. This is highly subjective but from the things I have tried so far it looks and feels more robust. It has currently the best documentation, more projects that actually use it, some useful examples and a big/healthy community around it. If I need to make something today, I would probably give this a try. The last time I tried it, it was probably a little bit weird API-wise but that is mostly due to the way Gtk works anyways, and nothing that would really hold you back. If you want to have something nicer try out Relm if it fits you better. My main problem with Gtk is the way it looks on Windows and MacOS by default. I am a Linux user and use Gnome most of the time so it perfectly fits my needs on Linux, but I have heard it looks very unnatural on other platforms (if you don't go with your own customized style).

Personally my main problem with these are that they "feel" really "unrusty" to begin with. If you have previously worked with projects from the e.g. "web department" of Rust it really feels unidiomatic at first. That's mostly due to the nature of binding frameworks that are supposed to be used with C/C++. The second problem is deployment. As a Rust user I am used to cargo build --release and be done. The problem with both approaches is to also ship the dependencies for Gtk/Qt. There is nothing particularly special about it and it's also fairly common if you're used to working with e.g. Qt and C++. But its quite different than your normal workflow in Rust, having most things statically linked.

Rust Centric Approaches

To overcome the problems we have with the other two approaches, many people started libraries with the goal to be more idiomatic and easier to use for Rust developers. Starting an API from scratch without sticking to an existing API from a binding can yield better results for Rust library users. It is also often the case that the build and deployment process is more in a way a Rust developer is used to. Add a dependency to Cargo.toml and you're good. No installation or deployments of Qt or other libraries which could get tricky if you are new to the field. It is far more accessible and a thing i really love about Rust. Unfortunately many projects have died along the way but they have paved the way by exploring the field.

This list is by no means exhaustive but contains some of the crates I could vividly remember. Conrod is some of the oldest in this field and has a long history in the Piston project. I feel like it is more geared towards game GUIs than your typical desktop application. Some people find it weird and others really like it for their special use case.

A crate to definitely look out for is Azul. Instead of drawing the GUI all by itself, Azul seeks to use WebRender as its drawing backend. Many people have suggested that this approach is the right way towards a Rust Centric Approach. I am really eager to see where this project is going in the year to come. It is not quite there yet and you should not try to build your GUI for the program you want to release in the next few months. But i think its a good idea to keep an eye on it, play around and give some feedback.

Another interesting approach just recently came up within the Redox-OS ecosystem. Redox has its own GUI library – OrbTk – and has undergone a huge restructuring and is now in the phase of rewriting. It is not as usable as Azul right now but is going at a huge pace you can follow at its issue tracker. The approach OrbTk chose is to have an abstraction for multiple rendering backends. OrbTk is primarily to render GUI on Redox with OrbClient. For other platforms the goal is to have exchangeable rendering backends like WebRender for Windows, Linux and macOS or stdweb for the browser and there are experiments with others like cairo. OrbRender is the project that should achieve this. OrbTk is heavily inspired by Flutter.

I mentioned the xi-editor earlier and its approach to stick to a "native" way of rendering for the different platforms. Raph Levien, the main author of the xi-editor, recently started an approach with druid as a way to have a cross-platform frontend for the editor. The approach we see here is with piet to build and idiomatic graphics library that is heavily inspired by the Skia Graphics Library that is used by e.g. Google Chrome and Flutter. Raph recently wrote a Blogpost about it.

And to have some good news in this field, WebRender was recently released to crates.io 🎉

Who needs GUI in the Rust-World?

I want to show you some evidence that there is a need for GUI development in Rust. In the last few years, the topic has come up occasionally from time to time. But the last year has struck me the most. Much more requests and questions about GUI programming on reddit. The emergence in the annual survey and in many #Rust2019 blog posts.

This years survey told us that there is a demand for GUI.

Nr.8 in the Survey

https://blog.rust-lang.org/2018/11/27/Rust-survey-2018.html#challenges

New this year is the rising need to support GUI development, showing that Rust continues to grow not only on the server, but that people are feeling the need to stretch into application development.

We also have some #Rust2019 blog post explicitly talking about GUI

Blog posts that mention GUI

Andre “llogiq” Bogus https://llogiq.github.io/2018/12/08/rust.html

a workable cross-platform GUI library that abstracts over the smallest, most thrifty platform libraries (sort of like a reduced FLTK, but with the components written in and for Rust and backends for Windows, MacOS, X11, Wayland, Android, iOS, perhaps WASM?)

Jonathan Turner https://www.jonathanturner.org/2018/12/the-fallow-year.html

Areas like GUI development need some clear direction and focus.

Amethyst https://www.amethyst.rs/blog/release-0-10/

The editor team is building editor prototypes to evaluate different application frameworks. There is currently an Electron prototype; Azul and orbtk are being looked at as potential alternatives.

Raph Levien https://raphlinus.github.io/rust/2018/12/16/rust-2019.html

Graphical user interfaces are a particular weak point for Rust right now, and I see the topic pop up quite a bit in Rust 2019 posts.

https://haurchefant.fr/posts/2018/12/my-wishlist-for-rust-2019/

There are lots of other cool GUI projects out there too. I personally feel Azul is one of the most promising, as I think WebRender is a good basis for building GUI. But there are things to be learned from Conrod, ggez, as well as wrappers for toolkits in other languages. It’s not surprising that much of the activity on GUI in Rust has a focus on games, and I think that’s a good thing.

Pascal Hertleif https://deterministic.space/rust-2019.html

What I want to set as goal is: At the end of the 2019, we should be at a point where we have a list of new things we want to be working on. “New stuff” is stuff we may have only considered in passing so far, but where no implementation exists today. But also, things we do not even consider “something that is great in Rust” today.

This is super abstract! In fact, can you quickly say what concrete things you thought of when you read “new things” above?

Did you think about the emergence of an idiomatic GUI library? Did you think about new working groups? Did you think about having const generics? Did you think about RFC process version 2? Did you think about having a having super fast debug builds? Those are all valid!

As a regular r/rust visitor i have seen a surprising amount of posts asking about the status of gui development. I wanted to keep track of it but at some point i just lost track but here is a small excerpt – i think you get the idea.

Reddit Posts

https://www.reddit.com/r/rust/comments/6qr11b/are_we_crossplatform_native_gui_yet/

Are we cross-platform native GUI yet? What is the current state of writing a native GUI app in Rust that could run on (at least) Windows and Linux, unmodified if possible? (I'd like to avoid electron and the like).

https://www.reddit.com/r/rust/comments/a0hijk/does_rust_have_a_working_gui_library_group/

I wonder if rust needs a group where some GUI experts and a few PL researchers can come together and decide how to make a Libra which is idiomatic rust and yet does only the bare minimum in the cross platform sense. Taking inspiration from how xamarin, silver (elements), sublime, gtk, qt etc do it.

more Posts

This is just to show you what its feels like on the rust subreddit, if you're not a regular visitor. But of course this is just one side and you could argue that those are just "random" questions from people who want to "play" around with the topic but this is not really i sign for real world demand. To try to give some examples for more "real world" need i have chosen to give some examples from projects i loosely follow:

previous attempts

We saw previous attempts to gather together people on multiple occasion but all of them slowly faded after the initial start.

I can't say why but it could have something to do with the accessability of those places. Threads in the forum simply disappear under the pressure of other topics. And basically no one knows about the gitter channel after a short amount of time. I hope areweguiyet can be that place that is easy to find for both users, creators and possible contributors and guide them in the right direction.

we don't want

We don't want the core Team to build or settle on a GUI framework. This is without question absolutely out of scope. GUI is hard and we have seen many attempts in different directions. It is very unclear what "The Rust GUI" should even look like. And i think it is very clear that we don't want the "only true" Rust GUI Framework. I also think that we don't want something like a official Workgroup. At least for now. The main reason for this is that currently we have many "one person" attempts to find a way through the jungle of possible technologies and thus it does not make sense to have some direct governance.

we do want

I think what we do want is a central place for people to engage in discussions about various topics and don't want to clutter Reddit or the userforum where things just get lost amongst all the other interesting topics. I think want we do want is help. Things are pretty time consuming especially on the coordination side. I think in the end this could lead to something like a working group. But realistically, currently the field is much too small now. I have something in mind like the way the Rust Game Dev is working out: Slowly but steadily increase visibility throughout the Rust ecosystem. For now, we just need a plan to come together and bikeshed some ideas by helping the projects currently existing, so those ideas do not die so fast as we've seen in the past. Maybe there are plans from the Rust (Community) Team to help to initiate such places that are not official Rust Working Groups. I haven't seen these plans yet. Maybe they do exist but if they don't this could be a wonderful way to sprout Rust in new directions.

To conclude this excessively long post: I hope you agree that there is demand for Rust GUI development. We cannot deliver the same experience we have in other programming languages right now but the seeds are planted! We want a place for people interested in this topic to come together and help guiding them in the right direction. Either as a library user or developers who want to contribute and find a crate to participate. I think a huge problem in the past was developers not knowing what others where doing and rather join forces than starting their own libraries which was doomed to fail as the workload is pretty high.

Lets come together and make 2019 the year we remember as leap towards great GUI crates!