Current state of GUI development in Rust?


@gbutler69 Good idea, but I think the library is simply too young for contributors. I’ve often seen it that young libraries create issues, then random people join in, then the dicussion gets bogged down in details and in the end, nobody writes any code. I’ve seen it happen so often, I think I’ll have to do it alone, at least for the 0.1 version. Most of the concepts may look good in discussions, but then in practice they don’t work well and I’m faster experimenting with this on my own than explaining what I mean to a different person.

Ex. I plan to implement animatable / dynamic properties using a special CSS syntax like:

#my_div {
    width: {{my_custom_id | 400}}px;

and then:

get_dom() { dom.window[window_id].css.set_animatable_property("my_custom_id", 300); }

(400px being the default, 300 px set by the Rust code, avoids re-parsing the CSS + webrender has special APIs for dynamic properties). But caching all that, implementing the webrender bindings, generating hit IDs / implementing that into the callback model… it simply takes experimentation. I have a rough idea of how I can solve it, and I think it’ll work this way, but I couldn’t really explain someone how to exactly code it.

There are issues unrelated to the code that would be great to be resolved - ex. the windows-gnu target doesn’t build because of a cmake error in a dependency. And the code coverage is displayed as 0% because codecov has a bug and coveralls doesn’t work at all, no matter what I try. That would be good issues to help out with…

@doomy Contributions are great, but I am a bit hesistant to accept PRs before 0.1 - I don’t want anyone to waste their time with a possibly vaporware project. It’s just that the library changes so quickly right now that I simply need to experiment with what works / what doesn’t. After 0.1 - yeah, I’ll happily accept PRs, because then people can somewhat see a certain architecture, then it’ll mostly be about fixing bugs. I don’t think the API will change much after 0.1, it’ll mostly be bug fixes.

As for financial support - I don’t really need money. If this library ever hits 0.1 I will have a product that uses this library. Maps4Print is my company, so if I can get this library done, I’ll have more money than I could ever get from patreon, because then I’ll have an actual product to sell. So that’s what’ll keep this library financially afloat (post-0.1). I’ve made this library for a specific purpose, not as a hobby project.

A large problem I see with many GUI libraries is that their authors don’t use them. They just create them, theorize about a hypothetical API that works in isolation, but don’t try to build a non-Hello-World product in it. Ex. Epic Games used their own engine to create games first and the success of these games then made the engine popular. Because they could show people: hey, you can actually build something large in this. So I’d first like to be sure that you can do that (build a maintainable product) before I go out and ask them to contribute.

As for a time limit… hopefully before October / November this year. If I’m not done by then, I’ll probably have another job and you can consider the project dead. Or fork it or whatever. But right now I don’t think I’ll need that long to release 0.1.


@sharazam - Thanks for the feedback. I completely understand where you’re coming from with regard to keeping it close to your vest until you have a 0.1. Good Luck! I look forward to seeing your results.


@rusty_ron I’m willing to try that (although python/tkinter is going fine), but the last time I looked at win32 was in the 90s with Petzold’s book… I wouldn’t know where to start now & prefer a book to online docs which are too big & overwhelming.


As for Gui development using QT, did you watch this presentation?


One problem with developing FOSS code is the trap where there is no documentation which stops people using the code which, in turn, limits the number of people with enough experience to write the documentation.

If I could make something basic work, I would contribute documentation. I experimented with Rust plus GTK but failed to make anything work. When I looked at Conrod, the documentation did not cover the minimum parts I would need for my starter project.


Note that many open-source projects compensate for their lack of documentation manpower by having someone available on a chat or mailing list to answer user questions.

Although not ideal (some users heavily dislike this organization, and it costs more accumulated developer time in the long run than writing the docs if one is being honest), this can help you get un-stuck when getting started with a given library.

Gtk-rs provides the following contact points for this purpose : .


I’ve actually been able to get everything I need from the gtk-rs docs. I think it is well documented, and the tutorials are how I got my application started. I regularly compile on both Ubuntu Linux and Mac and it works well.

On the occasions I have asked for help, I found the answer myself before anyone replied. I also use the C documentation for Gtk. Once you find what you’re looking for in C, it’s pretty easy to drill down and find it on too.

That being said, I haven’t tried to do anything too fancy like create a new GObject and register it yet. And it did take some time to read through the tutorials.


“GUI development” sounds like “settle on a GUI library, familiarize yourself with its (possibly huge) API, then link it to your Rust code”.

It’s a bit too much for me. I just wanted to add “draw something using Wayland” to my own rusty command-line toys, manually polling for window/input events.

Thus I tried the Smithay’s client toolkit (warning: still in development) to build a simple graphical app.

I also love that native-windows-gui (native for Windows Vista and newer, but you can safely test it with Linux and Wine); it should get more attention (and some new developer).


There is no such thing as “Drawing with Wayland”. Wayland is a compositor protocol. Nothing more. It doesn’t do any “drawing”. You use OpenGL, Cairo, or some similar API (or something higher-level on top) to “Draw/Render” to a surface/texture/framebuffer, and then you hand it off to a compositor using the “Wayland” protocol, and the compositor does its thing to render the screen. Again, there is no such thing as “Drawing with Wayland”.


That’s really exciting! Thank you for sharing this, I will follow this project.


Using servo seems to be quite simple

  • servo should be a crate
  • JavaScript events should be able to be caught and managed on the app side
  • and app side should dispatch event into an element in the DOM

This is the theory.

I am gonna try this one day…

Given servo as a crate I won’t need a local web server for system features.




iui looks good and uses libui. The iui code example looks better than other GTK+ code examples.

The main page for libui lists things not yet working. The first line of things not yet working is a list of the first things I need for my first application. I will give libui 6 months to develop then look at iui again.


Yes, by “drawing with Wayland” I actually meant writing 32-bit pixels to some screen descriptor having the Wayland handle the rest. My simple graphical app includes a bitmapped font and shows text by “writing” pixels.

When a full-blown and portable GUI is not needed, you may wish to do the same by writing pixels (u32) into a mmap’ed Linux display framebuffer (or u8 if text framebuffer), as I did a while ago I wrote my in-car monitoring app.


I am still waiting for a well maintained UI Binding too, which will be up to date with a little time difference or a pure Rust Solution as well.

I don’t like to handle a Server like Program and using a Browser and JS or Electron as UI.

For myself i decided to use python with wxPxthon phoenix binding and Rust for performance issues. One other Benefit of that is an existing UI Designer :).


Yay, Rust’s embeddable/FFI story doing exactly what it was intended for :tada:

As this thread makes obvious, a lot of people struggle with decisions like this, and could likely learn from your experience. Is your code available somewhere?
(or if I’m really greedy, would you be interested in writing a tutorial/code example? :blush: )

edit: I see you already provided some examples/help in another topic :heart::


Sadly my code does not exist in public space. But i really like to help other developer. I will come back to you if i will created a short tutorial so we can discuss about QA ;).


Yes, a few seconds before, i tried out and its working fine, but horrible slow. Thats the reason to prefer the way to return callbacks from rust code is more efficient :wink:


That’s OK, happens all the time with work-code :slight_smile:

I’ll gladly proofread anything you come up with! Feel free to PM me!


Please don’t. The whole idea of Rust is having a highly performing low-level safe language. Putting an interpreter (for HTML) in it breaks performance and safety. Putting JavaScript into it breaks performance at any level and also type safety. The JavaScript type system is a gigantic mess as indicated by this simple graphic:

Having both JavaScript and Rust modify resources will also break all the useful tools Rust gives you to ensure thread safety, memory safety and any kind of consistency.