13 ms·
Rust: State of GUI, December 2022
- phneutral26 4y agowow, really impressive!
- dfgdfgffd 4y agoSadly Rust for WinUI3/UWP/XAML for Windows GUI - actually modern UIs on Windows - was abandoned or explicitly removed from Rust API bindings by MS. The listed library only uses the ancient win32 api
- nickpp 4y agoAny idea why?! I find that the modern WinUI is impossible to use from any language other than .NET.
- Santosh83 4y agoPerhaps that's the plan?
- withinrafael 4y agoWe yanked it because, sadly, XAML/WinUI is squarely designed to be used with C# and Visual Studio. See also: https://github.com/microsoft/windows-rs/issues/2153#issuecomment-1312786179 https://github.com/microsoft/windows-rs/issues/2153#issuecom...
- yenhoo 4y agoSadly? I prefer desktop Windows programs to be gdi/win32, they are often the most thought out and optimized for actual desktop paradigms (i.e mouse+keyboard+high res screen) without giant margins, padding and whitespace everywhere and makes use of proper desktop class widgets like treeviews, listviews, tabs, etc.
- mm007emko 4y agoExactly. Haters gonna hate me but I really liked Windows.Forms (and C#) for development line-of-business desktop apps.
- pjmlp 4y agoNah, still quite good, although I personally would go with WPF, Forms is also quite good for what still matters on Windows desktop, just note that on the new runtime (.NET Core) there are still some issues with the out of process designer.
- dfgdfgffd 4y agoWindows offers multiple and mixed paradigms though, so ideally the UI needs to be able to adapt to and handle these paradigms
- pjmlp 4y agoDoesn't surprise me, the folks behind it are the same that caused the deprecation from C++/CX, the very first time that Microsoft had something comparable to C++ Builder in productivity for C++ RAD GUI development. It got replaced with C++/WinRT, which basically requires one to code like in the good old days of Visual C++ 6.0 alongside ATL, editing IDL files without any kind of VS tooling support and manually merging generated code. Even the eldery MFC has better VS tooling support and COM authoring APIs than C++/WinRT. Rust/WinRT is even years away from the C++/WinRT "productivity" in its current state, let along what .NET tooling provides, which by the way is also worse than UWP with .NET Native (e.g. no designer available, and no AOT support). The reality is that only WinDev folks actually care enough about WinUI, the rest of us have moved on burned by these rewrites, and only a few hardcore advocates keep showing up their community calls.
- onphonenow 4y agoWhich is a massive bummer because win ui stuff w designer etc used to be great and performed better than a lot of electron stuff and was easy to develop - but they have seriously trashed their ecosystem there
- pjmlp 4y agoYeah, if you browse around the public repos, and occasional community calls, it really seems that whoever is still around has no idea (experience) of what are the features of the frameworks they are trying to replace, and asking for yet another rewrite on top of all of those done since Windows 8 is trivial. Anyone that is still around beyond WinDev themselves just has too much sunk down cost into WinUI to switch for something else, even pre-Windows 8 stacks.
- zozbot234 4y agoIsn't that what the windows-rs crate is for? Doesn't seem abandoned.
- yencabulator 4y agoIt sure is abandoned: https://github.com/microsoft/windows-app-rs#this-repository-has-been-archived https://github.com/microsoft/windows-app-rs#this-repository-...
- fsloth 4y agowin32 api is pretty good. I don't see why you would want anything else for native app development. If you want to use the modern stuff it's far better to develop the UI frontend using Microsoft tools in C# and then use Rust as the backend. In this sense Rust story is not worse than C++ or C. If a person wants a native gui I guess QT would be worth investigating as well (unless one is concerned by the license).
- smasher164 4y agoOne thing I'd like to see are Rust bindings for wxWidgets. Contrary to the prevailing opinion, I think wrappers over native toolkits are a fine approach for cross-platform development.
- api 4y agoTake wxWidgets and wrap or modify it to implement a reactive programming model. No need to reinvent the lower levels and wrappers around native widgets are better for many use cases.
- pizza234 4y agoThere are pros and cons to the non-/native approaches. Writing effective cross-platform application is harder than one would think. Some time ago there was a discussion on HN where a WxWidgets maintainer stepped in to explain why some WxWidget programs were apparently inconsistent across O/S, and the explanation was that they were developed naively (I think one needs to use specific spacing abstractions, but I don't remember with exactness). For my personal development, I use non-native (which is easier to develop), however, on large scale, it'd be a tough decision. WxWidget was my favorite in the past (again, for personal development), however, the bindings are very spotty, which prevents adoption for several languages (wiki page: https://en.wikipedia.org/wiki/List_of_language_bindings_for_wxWidgets https://en.wikipedia.org/wiki/List_of_language_bindings_for_...).
- zackbrown 4y ago> Contrary to the prevailing opinion I'm not sure this is the prevailing opinion. It may be something of a "vocal minority" opinion, but it does seem more common in the Rust community than elsewhere. The closer you get to traditional native app designers and developers, the more you'll hear the opinion that native look & feel (not to mention accessibility) is important to embrace. IMO an ideal solution is to offer both: 1. to wrap native toolkits for things like text and UI controls, and 2. to enable canvas-drawn virtual controls, for those who would prefer to create their own widgets. These approaches can be enabled in parallel through an extensible widget/component system.
- nu11ptr 4y ago
- logicalshift 4y agoI've been working a 2D rendering toolkit that increasingly looks to me like it probably deserves a mention on these lists: https://github.com/logicalshift/flo_draw https://github.com/logicalshift/flo_draw (but I'm not on Reddit...). Layers, vector sprites, dynamic textures and a streaming API that fits well with 'reactive' designs are amongst the features that make it stand out from what else is out there. It's super simple to get going too. Started life as a rendering layer for FlowBetween so I could put in whatever looked like it was 'winning' later on but wound up writing my own renderer as there wasn't anything quite there yet. Still has that design so another unique thing is that it's possible to use the same API with whatever rendering layer you want. Speaking of FlowBetween, one thing I have wanted to do for ages is to get rid of the platform-specific GUIs and use something universal. It should be easy because FlowBetween sends straightforward instructions to an independent GUI layer, but I keep bouncing off for a few reasons: - it's a big ole task so I definitely want to pick something that's stable and also lets me hedge my bets in terms of being easy to migrate away from - most commonly, FlowBetween needs pressure data from tablets and a lot of frameworks just don't do that (this is also in a terrible state in browsers) - lots of GUI crates are designed as frameworks and so try to dictate the entire design of any app that uses them, which is no good for FlowBetween which tries to keep its internal design choices independent of its choice of GUI At the moment, I suspect that some sort of imgui framework is best along with an entirely manual implementation of tablet pointer data: fits with my existing design and isn't 'contagious' in a way that could make it hard to migrate to something else later on.
- jbk 4y agoHow many of those actually look and behave like native and support accessibility correctly?
- nicoburns 4y agoNone yet, but that is being worked on.
- Strom 4y agoWhat even is "native" on Windows? Is it Win32? WinForms? WPF? UWP? WinUI? Windows App SDK? There's so many to choose from and they all look and behave differently.
- 323 4y agoThese days the native GUI for Windows is Electron.
- pjmlp 4y agoNot quite, WebView2, which has the benefit of not dragging Chrome with every single application.
- izacus 4y agoAny of those will do as long as you don't drag in javascript crap.
- pjmlp 4y agoWin32, WinForms, WPF are as good as it gets, and really the only ones that matter. UWP is deprecated, althought it keeps being the one mostly used on Windows 11, as WinUI still isn't up to its game and keeps collecting issues across all their repos. Windows App SDK is not a GUI framework, rather the new marketing name for Project Reunion, the porting of UWP runtime infrastructure on top of standard COM without sandoxing and application identity.
- chronogram 4y ago
- 323 4y ago10 years ago Python was famous for how many web frameworks it had. It seems Rust will be famous for the number of GUI libraries.
- littlestymaar 4y agoOh, but Rust has even more web framework than GUIs libraries;).
- zackbrown 4y agoWhy? 1. Rust is growing in popularity, and a compelling GUI solution is needed 2. These solutions take significant time to incubate, so many of the ones we're seeing emerge have been incubating for months or years, started at a time when there were fewer options. 3. The implications for cross-platform app development with Rust are profound, and offer us a way to break free from the pain-points and shortcomings of the local maximum solutions du jour: Web + Electron and Phonegap-style WebView mobile apps.
- rtpg 4y agoA pretty fun Rust GUI experienc is vgtk[0], which is doing a bunch of macro magic to give a "we're coding in React" vibe to GTK+. I don't really have a specific thing I want to code in a native GUI at the moment but if I did I think this would be the most tempting for me. [0]: https://github.com/bodil/vgtk/ https://github.com/bodil/vgtk/
- fnord123 4y agoRelm4 is similar. https://relm4.org/ https://relm4.org/
- tristan957 4y agoFYI the project is called GTK, not GTK+, these days. They dropped it late in the 3.X cycle if I remember correctly.
- eklavya 4y agoFlutter app with rust core works great too.
- satvikpendem 4y agoYep, to be honest I don't think Rust has the manpower that Flutter has when it comes to writing a fully cross platform GUI. I simply don't expect anyone to be able to match Flutter or other similar frameworks like Qt without spending a lot of time and a lot of money.
- the__alchemist 4y agoOf the UI toolkits listed, it seems like Egui is nicest to use. It's flexible, has a nice collection of built-in widgets, is compatible with 3D graphics APIs (like WGPU), and has a clean API.
- Lichtso 4y agoShameless self promotion plug, I developed a GPU accelerated 2D rendering framework in Rust as well. It even comes with an experimental UI framework on top, which you can try in the browser if you have WebGPU enabled: https://github.com/Lichtso/contrast_renderer https://github.com/Lichtso/contrast_renderer
- terhechte 4y agoHey, I just ran the showcase locally. That looks super cool! Awesome project!
- Lichtso 4y agoThanks! You can also checkout the "feature/ui" branch in GIT [1] to get the UI framework prototype. [1]: https://github.com/Lichtso/contrast_renderer/tree/feature/ui https://github.com/Lichtso/contrast_renderer/tree/feature/ui
- bryanlarsen 4y agoShout out to Dioxus. It's a react clone that provides a really nice experience and can run a web GUI faster than React can. That's quite the accomplishment given the disadvantage of having to use shims to access the DOM. If you want to choose a single language that can create native GUI's, Rust is probably your best or only choice. Other languages are lacking a good story for either the web or for iOS but Rust works well on both.
- deleted 4y ago[deleted]
- mritchie712 4y agohave you built anything with it? We're using Tauri, but Dioxus looks very interesting.
- bryanlarsen 4y agoI have, but nothing used by more than 3 people.
- anon23anon 4y agoDoes Dioxus run in a webview on mobile? That's how I'm reading the docs.
- bryanlarsen 4y agoIn theory it doesn't have to. In practice, yes. My comment said that rust had a great cross-platform story, not Dioxus. If I was doing cross-platform rust I'd use cacao for iOS, Dioxus for web front end, et cetera.
- terhechte 4y agoI recently build this side project with Dioxus: https://terhechte.github.io/twitvault/ https://terhechte.github.io/twitvault/ Here's a review of the experience of using it: https://www.reddit.com/r/rust/comments/zegv2e/comment/izb6nl7/?utm_source=reddit&utm_medium=web2x&context=3 https://www.reddit.com/r/rust/comments/zegv2e/comment/izb6nl...
- phkahler 4y agoKAS will never be popular so long as it can only be used with Rust apps. It's still nice to see how Rust can be used in this context, but maybe make it into a wrapper for something more flexible.
- Strom 4y agoThis seems like a bad take on popularity. What exactly is the criteria here? Is Qt not popular because it's not a JavaScript framework? I think it's much more valuable to look at this from the viewpoint of the Rust GUI ecosystem, and not compare absolute numbers where nothing comes close to JavaScript .
- phkahler 4y agoQT and a JS framework are used in very different contexts. If your toolkit is aiming to work on Windows, MacOS, and Linux desktops, it is directly competing with QT, GTK, and Native (on all 3, and very few apps do separate native UI). Open source works better with a larger user base, so aiming for "Window, MacOS, and Linux RUST APPS" is terribly restrictive on the number of people who will use it and hence maintain it. I'm all for RIIR but it will take 30 years before enough has been rewritten for a Rust-only GUI to be viable IMHO.
- dohdhdaa 4y agoUnless a Rust OS is created with an official toolkit, Rust apps will always exist on a platform that already has a native toolkit. Any custom framework will always feel wrong and out of place. I use macOS, so apps should be written with AppKit. For Linux they should either be GTK or Qt, depending on desktop. Recreating widgets from scratch with GPU rendering is doomed to feel wrong to users.
- aaa_aaa 4y agoThat will probably be Fuchsia, if it lives.
- pjmlp 4y agoIts official GUI toolkit is Flutter.
- oDot 4y agoSome apps have their own unique look and that works quite well. Doesn't feel out of place for me.
- d12bb 4y agoDepends. Highly specialized apps (Blender comes to mind) fare better using custom toolkits. Anything else probably should use the platform-native one, not only for looks (lots of really great mac-only apps use customized widgets, see Things as example), but feel and integration as well.
- mroche 4y agoI feel like it's a spectrum. The simpler the app, the more likely it's better to try an integrate with a closer to native look. I always found the issue of "native" to be a bit funny to me as someone coming from the 3D/VFX space, since all of the applications are built to be multiplatform and don't give a hoot about "native". Consistency of the application experience across platforms trumps all. The number of people I've seen complain about this? Zero. Usually the only issues arise around file pickers (some have custom ones, others use platform ones which have differences). Granted these applications boast a ridiculous amount of features and are incredibly complex putting them on the opposite end of the spectrum compared to simple GUIs and chat/productivity applications. To me, it's nice that platforms provide native toolkits* to provide this level of integration. But I don't view any app as "native" unless it comes from the party making the platform, as they are really the only ones that actually have to adhere to their human interface guidelines to the fullest extent. * On Linux this is more up-in-the-air. I personally don't consider GTK and Qt as native toolkits, but the foundational pairing for things like libadwaita and KDE Frameworks which provide the associated platform widgets and HIG. Using the toolkits directly is fine and will mostly work, but it's not the same as a "native" application.
- robertkrahn01 4y agohttps://github.com/gabdube/native-windows-gui https://github.com/gabdube/native-windows-gui isn't in the list but is quite a polished option for building Windows specific GUIs. Seems to be the more mature option compared to winsafe.
- intelVISA 4y agoIs there a decent immediate mode GUI for Rust? Think ImGui, I know of eGui but unsure how workable it actually is in reality.
- rollcat 4y agoI've only had a very brief encounter with eGui (using Python+ImGui on a project), but I was very positively impressed by it. If we were starting that project today, we would've gone with eGui.
- cultofmetatron 4y agoI for one would love to see a toolkit akin to the user interface in blender. It would be a boon to anyone building 3d applications where high performance is necessary. (the kind of thing you'd probably want to use rust for anyway.)
- joshka 4y agoAnyone have a recommendation of what they'd use to run on a raspberry pi with a touch screen? My preference would be booting direct to the gui and having no other things running (i.e. X11 / etc.) as well as having a good development story for macOS. Is there something decent that enables this for rust? Bonus points for github example repos.
- kevin_thibedeau 4y agoQt is the most mature system for running on a framebuffer.
- eYrKEC2 4y agoI second this. I wrote an internal Qt/QML app that ran on Windows, Linux, Android, and Raspberry Pis. We had ~20 Raspberry Pi's running this app in kiosk mode. If only KDAB/cxx-qt[1] were ready then, I would have done as much as possible in rust . - [1] https://github.com/KDAB/cxx-qt/ https://github.com/KDAB/cxx-qt/
- joshka 4y agoNeat. Thanks!
- joshka 4y agoThat's pretty much the conclusion I'd come to when doing initial research. Good to know that others think the same. Mostly this is for the somewhere in the future type project we all have.
- worik 4y agoMy favourite GUI is and always will be the command line.
- fschuett 4y agoOne day I'll get around to finish my library Azul [1]. Hopefully. [1] https://azul.rs/ https://azul.rs/