For Rust programmers that want to write GUIs, I highly recommend gtk-rs. It does not have the easiest-to-read documentation in the world but it is a good wrapper of gtk and it suffices for production use. Although it has not reached 1.0 yet, the changes to the API are slow and mostly happen in esoteric corners, so the development cost of keeping up is not noticeable. Further, since cargo has good versioning, it won't update and surprise you.
Hi HN,
This is a work-in-progress project inspired by this HN comment[0].<p>[0]: HN comment -(<a href="https://news.ycombinator.com/item?id=19746440" rel="nofollow">https://news.ycombinator.com/item?id=19746440</a>)
For anyone else looking to get an overview of available GUI options in rust, there's <a href="https://areweguiyet.com/" rel="nofollow">https://areweguiyet.com/</a>
Good to see more alternatives in this space. If I can make one big app design request it would be this: Don’t assume that apps can always create their own windows. This has been a snag for winit and several others. Allow creating a GUI given an existing window handle.<p>See e.g. <a href="https://github.com/rust-windowing/winit/issues/159" rel="nofollow">https://github.com/rust-windowing/winit/issues/159</a><p>If you create a rust ui framework that supports the VST windowing/event loop model and just supports <i>one</i> GUI backend on Win32/MacOS, then many people in the audio plugin community would be very happy.
Interesting project, I’ll be checking this out soon.<p>I’ve been experimenting with several gui libraries in Rust lately and so far the GTK3 bindings seem to be the most promising for building native GUIs in Rust.<p>With native I mean GTK/Qt style fast/performant widgets that do not necessarily use platform-specific widgets.<p>This project seems to use GTK as one of its backends. I’m curious to see how the multiple backends architecture will influence the library design as GTK, html and TUI are vastly different.
I want a multi process GUI architecture that lets me send messages to a native rendering process from a bundled sub-process which can be written in any language. Is it a bad idea? I don’t see anybody trying this…
Since its a front end component and front end people are used to looking at gorgeous front ends and since you took the effort to make it functional (well done!) you should take the little bit of extra effort to also make it look pretty so it resonates with your audience. :). Rust is more a system language so you want to avoid that stigma from the outset.
This ui framework, if not abandoned by the tedium of win32 api integration, will make me sit up and actually try Rust for the first time. The TUI in particular looks great.<p>2020 was already slated for Rust for me but this may make me start dabbling in it a few months early (assuming I can find up to date leaning materials)<p>Tldr great job, please don't give up on the hard part of win32 and macos but this has a great foundation feature set.
It runs on wasm in a browser; not really mobile support.<p>...and the author is abandoning it to move on to other things?<p>/shrug<p>Didn’t solve any of the actually hard problems of a cross platform or rust based UI imo.