Rust: State of GUI, December 2022(kas-gui.github.io)
kas-gui.github.io
Rust: State of GUI, December 2022
https://kas-gui.github.io/blog/state-of-GUI-2022.html
148 comments
have you built anything with it? We're using Tauri, but Dioxus looks very interesting.
I recently build this side project with Dioxus:
https://terhechte.github.io/twitvault/
Here's a review of the experience of using it:
https://www.reddit.com/r/rust/comments/zegv2e/comment/izb6nl...
https://terhechte.github.io/twitvault/
Here's a review of the experience of using it:
https://www.reddit.com/r/rust/comments/zegv2e/comment/izb6nl...
Can you let me know about incremental compile times?
Basically with the HTML frameworks that use macros I'm getting incremental builds 10 seconds or more. Did you experience the same?
Basically with the HTML frameworks that use macros I'm getting incremental builds 10 seconds or more. Did you experience the same?
Incremental compile times were quite fast, I'd say in the 1-2 seconds. I also have another project where I'm using Dioxus-web for a web application. When building a web app, it also has hot code reloading and I'd say reloads take under a second (though I just started this app so it only has a couple hundred lines of code).
I have an M1 Pro Max though, which is quite a fast machine.
I have an M1 Pro Max though, which is quite a fast machine.
Thanks. I'll give it a try.
It's beautiful!
OT: it seemed like an awesome application so I ran it but a few seconds into importing I got
"Rate limit for Tweet Replies reached. Waiting 18446744072038294844 seconds"
I'm not going to live nearly long enough for that!
ADD: and there's no cancel button or anyway way to stop it.
OT: it seemed like an awesome application so I ran it but a few seconds into importing I got
"Rate limit for Tweet Replies reached. Waiting 18446744072038294844 seconds"
I'm not going to live nearly long enough for that!
ADD: and there's no cancel button or anyway way to stop it.
Does Dioxus run in a webview on mobile? That's how I'm reading the docs.
In 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.
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.
I have, but nothing used by more than 3 people.
[deleted]
kotlin is a decent choice as well
True. I forgot about the family of languages that will transpile to Javascript. That gives most of them a good web front end story, and of course Kotlin has a good iOS story.
I'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 (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.
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.
One 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.
> 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.
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.
There 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_...).
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_...).
I think after years of agreeing with you I might actually disagree in 2022. I also prefer native widgets, but the problem is native programs have changed. It used to be they all looked very sterile and had 80-90% of the same widgets as every other OS, but if you look at apps today they are all much more media centric. Whether electron or native it is very common to have things like a "side bar" and other very specific widgets. These don't translate well to cross platform native widgets. I think Flutter might have the right approach with its fluent UI and macos libraries. I suspect the resulting app would look much more native in this day and age.
I agree that GUIs have gotten more complicated nowadays, but I don't think the existence of platform-specific APIs is mutually exclusive with cross-platform abstractions. If anything, you should be able to specialize behavior for a certain platform.
I agree, but no one has done it successfully either. In wxWidgets any non-native widgets look very out of place. Some of the ones on Qt do as well. Neither of them that I've seen try to map to the more exotic widgets, but invent some of their own.
Take 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.
It looks like the author of wxRust is attempting another go at bindings with https://github.com/kenz-gelsoft/wxRust2.
Sadly 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
The listed library only uses the ancient win32 api
Doesn'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.
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.
Which 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
Yeah, 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.
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.
Sadly?
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.
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.
Exactly. Haters gonna hate me but I really liked Windows.Forms (and C#) for development line-of-business desktop apps.
Nah, 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.
Windows offers multiple and mixed paradigms though, so ideally the UI needs to be able to adapt to and handle these paradigms
Any idea why?! I find that the modern WinUI is impossible to use from any language other than .NET.
We 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#issuecom...
See also: https://github.com/microsoft/windows-rs/issues/2153#issuecom...
Perhaps that's the plan?
win32 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).
If a person wants a native gui I guess QT would be worth investigating as well (unless one is concerned by the license).
Isn't that what the windows-rs crate is for? Doesn't seem abandoned.
It sure is abandoned: https://github.com/microsoft/windows-app-rs#this-repository-...
Unless 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.
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.
> Recreating widgets from scratch with GPU rendering is doomed to feel wrong to users.
So following your argument, pretty much all apps I use on macOS are 'wrong' as far as GUI goes.
Off the top of my head from what I use most of the time: Maya, Houdini, Blender, Fusion360, Resolve, Darktable, Slack, Discord, VSCode. Not a single one of them uses native Cocoa widgets. And I couldn't care less.
Some of these are top of the line apps for 2D/3D content creation on that platform.
If the vendors of these apps can afford to not care about UI nativeness, why should any single one or small group of developers working their asses off on GUI crates for Rust? Mostly unpaid no less.
So following your argument, pretty much all apps I use on macOS are 'wrong' as far as GUI goes.
Off the top of my head from what I use most of the time: Maya, Houdini, Blender, Fusion360, Resolve, Darktable, Slack, Discord, VSCode. Not a single one of them uses native Cocoa widgets. And I couldn't care less.
Some of these are top of the line apps for 2D/3D content creation on that platform.
If the vendors of these apps can afford to not care about UI nativeness, why should any single one or small group of developers working their asses off on GUI crates for Rust? Mostly unpaid no less.
> Not a single one of them uses native Cocoa widgets. And I couldn't care less.
Meanwhile I do care. My main reason being: macOS offers fantastic facilities for inspecting and scripting the native GUIs, think using the web inspector or GreaseMonkey, but across the entire OS - but of course it breaks e.g. on Electron apps. Other people will cite help menu integration, custom key shortcuts, accessibility (not only for the disabled), and - yes, resource usage. I remember being productive on a system with 256M of RAM, and before that - 4M, and before that - 64k. It's frustrating to see so much progress wasted, I shouldn't need to close ALL of the chat apps just to run StableDiffusion more smoothly.
Meanwhile I do care. My main reason being: macOS offers fantastic facilities for inspecting and scripting the native GUIs, think using the web inspector or GreaseMonkey, but across the entire OS - but of course it breaks e.g. on Electron apps. Other people will cite help menu integration, custom key shortcuts, accessibility (not only for the disabled), and - yes, resource usage. I remember being productive on a system with 256M of RAM, and before that - 4M, and before that - 64k. It's frustrating to see so much progress wasted, I shouldn't need to close ALL of the chat apps just to run StableDiffusion more smoothly.
Maybe Apple should write libraries for their GUI toolkits, then. It's awfully hard to beg people to write native apps for you when people need to learn a new language to do it.
And when that new language is Swift. Coming from Rust Swift is hard to take.
That's more-or-less what I'm getting at. Apple can't replace Objective-C with Swift and expect people to not cock their head. They can either support a pre-existing language (like Microsoft with Rust) or home-bake something suitable for low-level development. Telling developers to not use the stuff they want to use sorta leaves their hands tied.
Microsoft's Rust support is basically non-existing for GUI applications, Rust/WinRT is miles away from achiving C++/WinRT parity, even more so with C#.
In its current state is only useful for CLI or services, unless you feel like doing WinUI team's work for free.
In its current state is only useful for CLI or services, unless you feel like doing WinUI team's work for free.
> So following your argument, pretty much all apps I use on macOS are 'wrong' as far as GUI goes.
MacOS apps feel pretty wrong to me.
Some don't remember which screen they should be on, and always go to that screen at a predetermined size and geometry (tkdiff).
Others expand incorrectly to full-screen (macvim) when moved to a different screen.
VSCode doesn't behave like the native apps.
The list goes on, I'm short on time.
> And I couldn't care less.
You caring or not doesn't make the problem go away - native widgets always feel less wrong than non-native widgets.
MacOS apps feel pretty wrong to me.
Some don't remember which screen they should be on, and always go to that screen at a predetermined size and geometry (tkdiff).
Others expand incorrectly to full-screen (macvim) when moved to a different screen.
VSCode doesn't behave like the native apps.
The list goes on, I'm short on time.
> And I couldn't care less.
You caring or not doesn't make the problem go away - native widgets always feel less wrong than non-native widgets.
My main counter argument would be that most of the tasks I do on macOS require/are better done full screen.
And if you are on macOS doing any kind of design work, this is your mode of working. People using Photoshop or any 2D/3D DCC etc. You use all the screen space real estate on any number of screens you have. But even if I write code I run VSCode in full screen. If I have a dual screen setup I usually have one screen with two code editors, mini map & folders + terminal on screen two. But that's it.
But even assuming you run apps side by side/stacked whatever so you could actually visually see how non-native/different they look. Is that the real issue on macOS today? Personally the main gripe I have is that -- and kindly pardon the tangent -- macOS native window management is shite. One of the first things people that come from a *nix desktop buy/install, when they switch to macOS, is a proper (possibly tiling) window manager.
But back to widgets/look: in DCC apps the main sort of dialog you interact with are attribute editors where you change properties of an object or node.
I like to refer to an issue on the egui crate which has some of the best out-of-the-box support for this kind of widget composition[1].
Apple Human Interface (AHI) guidelines do not have any handrails on how these attribute editors should look or be done. The best you can do is go with dialog AHI guidelines and these fall short for this sort of window. I can go into great detail here why but it's beside the point. If you read my comment on the egui issue I linked above (same handle I use on HN) you may get an idea where I am coming from.
Most Human Computer Interface (HCI) guidlines for various platforms are based on typical late 90's early 2k desktop apps.
They were never updated to reflect on newer paradigmns for UX that evolved in recent years. Blame the fragmentation of the desktop and Electron & co.
IMHO this is the first problem the OS vendors need to solve before we can blame developers of UI libs to not make them look 'native enough'.
[1] https://github.com/emilk/egui/issues/88
And if you are on macOS doing any kind of design work, this is your mode of working. People using Photoshop or any 2D/3D DCC etc. You use all the screen space real estate on any number of screens you have. But even if I write code I run VSCode in full screen. If I have a dual screen setup I usually have one screen with two code editors, mini map & folders + terminal on screen two. But that's it.
But even assuming you run apps side by side/stacked whatever so you could actually visually see how non-native/different they look. Is that the real issue on macOS today? Personally the main gripe I have is that -- and kindly pardon the tangent -- macOS native window management is shite. One of the first things people that come from a *nix desktop buy/install, when they switch to macOS, is a proper (possibly tiling) window manager.
But back to widgets/look: in DCC apps the main sort of dialog you interact with are attribute editors where you change properties of an object or node.
I like to refer to an issue on the egui crate which has some of the best out-of-the-box support for this kind of widget composition[1].
Apple Human Interface (AHI) guidelines do not have any handrails on how these attribute editors should look or be done. The best you can do is go with dialog AHI guidelines and these fall short for this sort of window. I can go into great detail here why but it's beside the point. If you read my comment on the egui issue I linked above (same handle I use on HN) you may get an idea where I am coming from.
Most Human Computer Interface (HCI) guidlines for various platforms are based on typical late 90's early 2k desktop apps.
They were never updated to reflect on newer paradigmns for UX that evolved in recent years. Blame the fragmentation of the desktop and Electron & co.
IMHO this is the first problem the OS vendors need to solve before we can blame developers of UI libs to not make them look 'native enough'.
[1] https://github.com/emilk/egui/issues/88
On that tangent what are the top alternative window managers people here use on macOS? The native window management does indeed drive me up the wall.
>newer paradigmns for UX that evolved in recent years.
can you provide some examples on desktop? Touch maybe, but that is not used on desktop, afaik.
can you provide some examples on desktop? Touch maybe, but that is not used on desktop, afaik.
I should probably have said patterns, not paradignms but this beside the point.
I mean stuff that is common enough to deserve a defintion and a best practice laid out in a human computer interface (HCI) guideline document for a platform/OS.
Off the top of my head:
Tab closing behaviour on Chrome/FF. Close a tab, other tabs shift but don't change size immediately so you the next tab's close button is directly under the mouse and can bel clicked to close another tab (and another, and ...).
Another one: the typical chat app with servers/groups/contacts on a list on the left and the chat on the right (and possibly threads on the far right).
There is no good standard for this, everyone cooks their own soup so stuff you learned for Slack doesn't apply in Discord etc. I.e. it's a pattern of some sort but there are no Windows/macOS/Qt/GTK interface guidelines covering this case and/or suggesting best practices. This includes e.g. platform standard keybindings to select stuff in such apps (at best Tab switching works).
Another one is use of (some) Markdown-inspired stuff in chat apps. I.e. `monospaced` ```monospaced multline``` or even ```<language for syntax highlighting> ...```.
In Slack ``` works but ```<lang> doesn not (but does in Discord, used to work in Slack in the past, I think).
I think there are many such patterns that are maybe not as groundbreaking than the invention of tabs (90's?), combo boxes/menus (also 90's? When there are too many choices for radio buttons) etc.
But beause they are used in some form (or another, unfortunately) by many apps now, the OS vendors should define a best practice for implementing their end-user facing functionality/behavior in their HCI guidelines.
Even if the platform itself doesn't provide a ready-made widget for each such case.
Hope that makes sense and explains what I meant.
I mean stuff that is common enough to deserve a defintion and a best practice laid out in a human computer interface (HCI) guideline document for a platform/OS.
Off the top of my head:
Tab closing behaviour on Chrome/FF. Close a tab, other tabs shift but don't change size immediately so you the next tab's close button is directly under the mouse and can bel clicked to close another tab (and another, and ...).
Another one: the typical chat app with servers/groups/contacts on a list on the left and the chat on the right (and possibly threads on the far right).
There is no good standard for this, everyone cooks their own soup so stuff you learned for Slack doesn't apply in Discord etc. I.e. it's a pattern of some sort but there are no Windows/macOS/Qt/GTK interface guidelines covering this case and/or suggesting best practices. This includes e.g. platform standard keybindings to select stuff in such apps (at best Tab switching works).
Another one is use of (some) Markdown-inspired stuff in chat apps. I.e. `monospaced` ```monospaced multline``` or even ```<language for syntax highlighting> ...```.
In Slack ``` works but ```<lang> doesn not (but does in Discord, used to work in Slack in the past, I think).
I think there are many such patterns that are maybe not as groundbreaking than the invention of tabs (90's?), combo boxes/menus (also 90's? When there are too many choices for radio buttons) etc.
But beause they are used in some form (or another, unfortunately) by many apps now, the OS vendors should define a best practice for implementing their end-user facing functionality/behavior in their HCI guidelines.
Even if the platform itself doesn't provide a ready-made widget for each such case.
Hope that makes sense and explains what I meant.
A good "tiling helper" is Rectangle Pro. The basic version does enough, but the paid one is a game changer.
>Maya, Houdini, Blender, Fusion360, Resolve, Darktable, Slack, Discord, VSCode. Not a single one of them uses native Cocoa widgets.
Also Firefox and Chrome and their forks (e.g., Brave).
Also Firefox and Chrome and their forks (e.g., Brave).
It seems to me Mac users care about using native UI toolkits more so than Linux or even Windows users. I would suppose that has to do with how polished and integrated that platform is.
As a Linux user I really don't care if you use GTK for the UI. I've long given up on customizing the look and feel of my system to the point that application integration matter.
As a Linux user I really don't care if you use GTK for the UI. I've long given up on customizing the look and feel of my system to the point that application integration matter.
For many decades, there have existed commercial apps native to the Apple ecosystem, often from small/mid-sized studios, which would use native UI to signal their premium craftsmanship. I think that for many long-time Mac users, seamless/native UI is still a signal of quality in third-party software. However, this sentiment is moribund. That entire market is now dwarfed by the ecosystem of “cross-platform apps” (formerly Windows ports, now usually web apps) and Unixy OSS tools; all the while the Mac App Store now peddles lots of native-UI apps of deeply questionable quality.
long ago, the integrated feeling of Apple MacOS was a great selling point; decades later, daily use of the web, more phone than desktop, Windows low-bar junk and other factors change the equation.
If a smart user here today says that recent network-centric apps are OK with him visually, then maybe they are OK?
If a smart user here today says that recent network-centric apps are OK with him visually, then maybe they are OK?
I think Apple made a strategic error when they failed to embrace DOM/browser engine-based toolkits like Electron on the Mac. If they had applied their leverage, of which they have plenty, the technical challenges of better native integration and support for the wide range of traditional Mac affordances would seem to have been quite manageable.
There's some reason to your proposition. Directly integrating/"embracing" foreign toolkits/web engines is the last thing Apple would ever do, but exposing more of the underlying machinery to allow third parties to integrate better - yeah, sounds good.
On the topic of Rust GUIs on Mac, this was recently in the news:
https://github.com/emilk/egui/commit/e1f348e4b24c2fa83d25c6a...
On the topic of Rust GUIs on Mac, this was recently in the news:
https://github.com/emilk/egui/commit/e1f348e4b24c2fa83d25c6a...
This. It’s so lame when UI elements can’t hang outside the bounds of the window (i.e. menus, tooltips, dropdowns, popovers) because everything is rendered like a game…
There's no reason Rust toolkits can't use separate windows for elements like menus and tooltips, and I know this is planned for at least some of the toolkits discussed in the post.
The problem right now the separation of concerns for GUIs is a complete shitshow on ALL platforms.
Even such "simple" tasks as how to composite a window, a video in that window, and a floating menu over that window are not very well specified in any OS (try resizing that window and watch the fun). Or, for example, your floating menu--should the parent window resize itself and paint with transparent pixels in the extra area or should that menu be a separate "window"? And, what does being a "window" even mean?
Add into that the fact that we really should be making multithreaded GUI systems at this point and it's very clear that GUIs are stuck in a local minimum that's really hard to get out of because GUI systems require so many lines of code.
Even such "simple" tasks as how to composite a window, a video in that window, and a floating menu over that window are not very well specified in any OS (try resizing that window and watch the fun). Or, for example, your floating menu--should the parent window resize itself and paint with transparent pixels in the extra area or should that menu be a separate "window"? And, what does being a "window" even mean?
Add into that the fact that we really should be making multithreaded GUI systems at this point and it's very clear that GUIs are stuck in a local minimum that's really hard to get out of because GUI systems require so many lines of code.
Window resizing works perfectly fine on macOS if you use the native AppKit framework. It’s only when you try to embed a whole different world (Qt, GTK, Flutter, Electron) in your window via an opaque OpenGL/Metal surface that things break/lag/distort on resizing the window, which again is another reason to stay away from these cross-platform GUI shims.
I don’t really see the reason for multithreaded UIs either. A single UI thread works perfectly fine if you move your business logic off to a separate thread. Most people are just too lazy to do that, and start developing their app with the business logic running synchronously on the UI thread; which works for a while, but eventually reaches a point where it starts blocking the UI event loop; then they try bandaging it by moving certain pieces to a background thread and they shoot themselves in the foot with thread-safety issues. The way to solve this is not by making the UI framework multi-threaded… Simply be disciplined with UI ↔ business logic separation from the get go and all these problems go away. Yes, I know it’s so tempting to call the database directly from the button click handler - but don’t do it.
I don’t really see the reason for multithreaded UIs either. A single UI thread works perfectly fine if you move your business logic off to a separate thread. Most people are just too lazy to do that, and start developing their app with the business logic running synchronously on the UI thread; which works for a while, but eventually reaches a point where it starts blocking the UI event loop; then they try bandaging it by moving certain pieces to a background thread and they shoot themselves in the foot with thread-safety issues. The way to solve this is not by making the UI framework multi-threaded… Simply be disciplined with UI ↔ business logic separation from the get go and all these problems go away. Yes, I know it’s so tempting to call the database directly from the button click handler - but don’t do it.
What you are talking about has nothing to do with custom vs native controls. Instead it's a question of using a single or multiple windows.
There are Rust GUI toolkits like Druid with custom controls that have elements outside the bounds of the main window.
There are Rust GUI toolkits like Druid with custom controls that have elements outside the bounds of the main window.
The only cross platform toolkit that pulls it off well is Java. IntelliJ feels good on every platform. Qt apps can also feel native if a little effort is put into it. Rust GUI frameworks are one of its weaker areas IMO.
The next time you use a Swing app, look for these examples of how it "pulls it off well":
* The first time any particular window is opened, Swing draws the contents but then changes its mind about the window size, recalculates the layout and then redraws the contents again slightly differently.
* When Swing creates a window, you can sometimes observe how creates it in the wrong spot and then moves it to where it was supposed to be created.
* Alt-tabbing quickly between two windows in a Swing application doesn't always work. It sometimes just glitches and leaves you in the window you started with. (Confirmed just now on Windows 10 with Java 17. The bug has been there for many, many years.)
* When opening a submenu of a menu, Swing does nothing to handle the problem of the menu closing again as you're moving towards it but accidentally mouse over an adjacent item. Platform GUI toolkits solve this either with a delay or by tracking the direction of the movement. IntelliJ implements its own menu bar to make this work.
* Try to find an example of a window that is resizable in only one direction or only up to a certain maximum size. As far as I can tell, this is not possible in Swing, and applications handle this limitation by designing all UIs to be resizable even when it doesn't make any sense.
* The first time any particular window is opened, Swing draws the contents but then changes its mind about the window size, recalculates the layout and then redraws the contents again slightly differently.
* When Swing creates a window, you can sometimes observe how creates it in the wrong spot and then moves it to where it was supposed to be created.
* Alt-tabbing quickly between two windows in a Swing application doesn't always work. It sometimes just glitches and leaves you in the window you started with. (Confirmed just now on Windows 10 with Java 17. The bug has been there for many, many years.)
* When opening a submenu of a menu, Swing does nothing to handle the problem of the menu closing again as you're moving towards it but accidentally mouse over an adjacent item. Platform GUI toolkits solve this either with a delay or by tracking the direction of the movement. IntelliJ implements its own menu bar to make this work.
* Try to find an example of a window that is resizable in only one direction or only up to a certain maximum size. As far as I can tell, this is not possible in Swing, and applications handle this limitation by designing all UIs to be resizable even when it doesn't make any sense.
I have never had anything other than a terrible experience with a Java app, under Windows, Linux (in GNOME 2 and Unity most of a decade ago, i3, or Sway). They always disregard platform conventions in both look and feel to a painful extent. But I will declare that I haven’t ever used IntelliJ, and I have no idea what it uses for its UI. But out of the box, Qt seems vastly better at matching platform look and feel, and generally gives you decent control over matching or not to match your requirements.
I use intellij on Linux and macos.
It looks mostly ok, but on Linux it doesn’t support smooth scrolling (even though this is supported by gtk). You also can’t use the meta key (windows key / cmd) as a modifier key for keyboard shortcuts. So I can’t configure intellij to use all the keyboard bindings I’m used to from macos. Again, this isn’t a problem with other gtk apps. It’s just (apparently) a platform limitation of whatever Java toolkit they’re using.
So in my experience it’s 95% of the way there. I certainly prefer it over Xcode, but it has issues that native apps don’t have.
It looks mostly ok, but on Linux it doesn’t support smooth scrolling (even though this is supported by gtk). You also can’t use the meta key (windows key / cmd) as a modifier key for keyboard shortcuts. So I can’t configure intellij to use all the keyboard bindings I’m used to from macos. Again, this isn’t a problem with other gtk apps. It’s just (apparently) a platform limitation of whatever Java toolkit they’re using.
So in my experience it’s 95% of the way there. I certainly prefer it over Xcode, but it has issues that native apps don’t have.
SWT was pretty good in my experience.
SWT is even better now.
First of all, up-to-date official packages are now published to Maven Central as part of the release process, so you can just add it as a dependency as easily as with any other library. Until recently you would have had to either fiddle around with Eclipse's alternative package management system, download it manually or use someone's unofficial Maven artifact. But that's now resolved.
Secondly, if you bundle a Java runtime customized with jlink (as is recommended these days), an SWT application is actually smaller than a Swing application. When you don't use Swing, you can exclude the entire "java.desktop" module, which is slightly larger than the SWT libraries.
First of all, up-to-date official packages are now published to Maven Central as part of the release process, so you can just add it as a dependency as easily as with any other library. Until recently you would have had to either fiddle around with Eclipse's alternative package management system, download it manually or use someone's unofficial Maven artifact. But that's now resolved.
Secondly, if you bundle a Java runtime customized with jlink (as is recommended these days), an SWT application is actually smaller than a Swing application. When you don't use Swing, you can exclude the entire "java.desktop" module, which is slightly larger than the SWT libraries.
Regarding Java I think that's more of a Jetbrains thing that IntelliJ feels good on every platform than Java per se. Contrast it with Netbeans for a more "pure" Java desktop experience.
I've been an JetBrains (IntelliJ and these days CLion) user since about 2004 and what I'd say is this was a hard fought and slow incremental advancement. Back in the 00s, IDEA's UI experience was really sub-par and its foreign nature on the platform was very very clear.
It's amazing the amount of work JetBrains has put into this.
It's amazing the amount of work JetBrains has put into this.
When it comes to Java GUIs, Intellij is the exception, not the rule.
Ahh, well, it is the only one I use so, just a slight bias there :-D
It’s mostly an IntelliJ thing. All other Java apps are ugly and weird.
And there are non-native behaviors in IntelliJ too. For example you can’t close windows by double-clicking the window icon on Windows (a feature of Windows since Windows 1?).
And there are non-native behaviors in IntelliJ too. For example you can’t close windows by double-clicking the window icon on Windows (a feature of Windows since Windows 1?).
> Unless a Rust OS is created with an official toolkit, Rust apps will always exist on a platform that already has a native toolkit.
If the toolkit is good enough it's entirely possible that a platform or platforms may adopt it as their native toolkit. In any case, these are really competing with electron which is already non-native. If Rust toolkits can get to electron-like quality but with lower resource usage and better hooks into the underlying platform then I'd consider that a success.
If the toolkit is good enough it's entirely possible that a platform or platforms may adopt it as their native toolkit. In any case, these are really competing with electron which is already non-native. If Rust toolkits can get to electron-like quality but with lower resource usage and better hooks into the underlying platform then I'd consider that a success.
With exception of VSCode, the only Electron apps that I use are forced upon me due to work requirements.
All of them I glady ignore on private owned computers, or use the browser version, they are anyway Web apps.
All of them I glady ignore on private owned computers, or use the browser version, they are anyway Web apps.
> In any case, these are really competing with electron which is already non-native
Use Electron and you'll get OS-native buttons and other form controls.
Use Electron and you'll get OS-native buttons and other form controls.
Can you provide any source/documentation on how to achieve this?
As far as I know Electron is based on Chromium. And Chromium doesn't use native controls, it has its own custom controls that sometimes look similar to native controls.
As far as I know Electron is based on Chromium. And Chromium doesn't use native controls, it has its own custom controls that sometimes look similar to native controls.
Some apps have their own unique look and that works quite well. Doesn't feel out of place for me.
Depends. 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.
I 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.
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.
You can write GTK applications in Rust: https://www.gtk.org/docs/language-bindings/rust/
You can, but its documentation is (was?) a horrid mess of C examples that make it quite difficult to navigate.
This was my experience as well. Simple windows with a button that increments a number are nice and understandable but if you try to get more complex controls working, you run into docs.
With C code often being unreadable, I found that Vala applications often have readable examples of how to use UI components. However, tooling support for Vala is extremely limited so experimenting with existing code may be a annoying. That said, I've had good experiences with opening these projects in Gnome Builder (once it got updated to work on my computer again).
If your component of choice doesn't have a Vala example, I'd resort to reading the documentation. Reverse engineering the API from the docs is often quite doable if you first look at how a component you do understand.
I've had similar problems, but worse, when I tried mixing Rust and Qt. I've never used Qt before so that doesn't help, but I found the API even less predictable in many cases, with some docs and examples several versions out of date.
I'd seriously consider just shipping a WINE'd Windows binary (using a tool like https://winepak.github.io/) for Linux targets with the current state of Rust GUI platforms. The amount of game UI/custom UI libraries out there is impressive but they all feel terribly wrong when I try to use them, in the same way most Flutter apps are terrible to use on desktop.
With C code often being unreadable, I found that Vala applications often have readable examples of how to use UI components. However, tooling support for Vala is extremely limited so experimenting with existing code may be a annoying. That said, I've had good experiences with opening these projects in Gnome Builder (once it got updated to work on my computer again).
If your component of choice doesn't have a Vala example, I'd resort to reading the documentation. Reverse engineering the API from the docs is often quite doable if you first look at how a component you do understand.
I've had similar problems, but worse, when I tried mixing Rust and Qt. I've never used Qt before so that doesn't help, but I found the API even less predictable in many cases, with some docs and examples several versions out of date.
I'd seriously consider just shipping a WINE'd Windows binary (using a tool like https://winepak.github.io/) for Linux targets with the current state of Rust GUI platforms. The amount of game UI/custom UI libraries out there is impressive but they all feel terribly wrong when I try to use them, in the same way most Flutter apps are terrible to use on desktop.
> Any custom framework will always feel wrong and out of place
Pretty sure that's the wrong metric. Users don't care if the interface doesn't look exactly like the rest as long as it's good looking and feels familiar.
As a heavy VSCode user for example, I don't think it feels out of place on a mac for example. The UI is consistent in itself, and the UX is consistent with the global UX of the OS (more so than some native mac apps like Finder for instance).
The main reason I hated Java Swing apps was that they were ugly as hell, not that they didn't feel native.
Pretty sure that's the wrong metric. Users don't care if the interface doesn't look exactly like the rest as long as it's good looking and feels familiar.
As a heavy VSCode user for example, I don't think it feels out of place on a mac for example. The UI is consistent in itself, and the UX is consistent with the global UX of the OS (more so than some native mac apps like Finder for instance).
The main reason I hated Java Swing apps was that they were ugly as hell, not that they didn't feel native.
I'm the author of cacao, which is the first thing in this blog post - and is a Rust wrapper around native AppKit. Anything built with it feels fine on macOS and gets most things "for free", but the issue is that nobody wants to write AppKit anymore. ;P
You can blame a variety of things for this, but it's the reality. Apple doesn't really make it easier with the newer UI approaches creeping in.
You can blame a variety of things for this, but it's the reality. Apple doesn't really make it easier with the newer UI approaches creeping in.
The first item on the list is cacao, the rust bindings for AppKit. And that is IMO the best option for building MacOS apps in rust.
>For Linux they should either be GTK or Qt, "depending on desktop"
That's bad... ideally there should be a runtime choice between GTK / Qt.
side note... I know many people that would prefer apps on MacOS to behave like Windows/Linux (mostly about the keyboard)... and also the reverse (those are louder to complain, but a minority in my case).
That's bad... ideally there should be a runtime choice between GTK / Qt.
side note... I know many people that would prefer apps on MacOS to behave like Windows/Linux (mostly about the keyboard)... and also the reverse (those are louder to complain, but a minority in my case).
I think, now in 2022 it is time to let go of this idea (for cross-platform applications). What you propose means that any app that wants to be available on "all" desktop platforms has to be written at least 4 times (macOS, Windows, GTK, Qt) and few developers or organizations have the resources for that.
> Recreating widgets from scratch with GPU rendering is doomed to feel wrong to users.
Yes, and no. When these widgets try to mimic platform-native widgets we have the uncanny valley problem which makes everything feel out of place like you describe. But if we drop this constraint and design widgets with their own consistent style within the same app, we don't have this problem. Apps like the JetBrains IDE's and Todoist show that this can be done.
To me the middle-ground solution is a UI toolkit with its own widget style, that has some tie-in with platform-native things and conventions like windows, menus, notification trays and keyboard shortcuts. Essentially GTK or Qt without the focus on pixel-perfect matching of platform-widgets. I think this is what Druid is doing. Rust is in a good place for this as it is a modern language that works well on all of these platforms, with no native UI toolkit yet and a package-manager/build-system that supports multi-platform library configuration.
There will always be a place for platform-native apps but cross-platform apps have different requirements. I don't care that my todo list application or IDE does not look exactly "native" on my Macbook. However I do care that these applications look and feel similar when I use them on my Macbook vs on my Linux machines or Windows laptop. Preferably without dragging in a full web-based rendering engine a la Electron.
> Recreating widgets from scratch with GPU rendering is doomed to feel wrong to users.
Yes, and no. When these widgets try to mimic platform-native widgets we have the uncanny valley problem which makes everything feel out of place like you describe. But if we drop this constraint and design widgets with their own consistent style within the same app, we don't have this problem. Apps like the JetBrains IDE's and Todoist show that this can be done.
To me the middle-ground solution is a UI toolkit with its own widget style, that has some tie-in with platform-native things and conventions like windows, menus, notification trays and keyboard shortcuts. Essentially GTK or Qt without the focus on pixel-perfect matching of platform-widgets. I think this is what Druid is doing. Rust is in a good place for this as it is a modern language that works well on all of these platforms, with no native UI toolkit yet and a package-manager/build-system that supports multi-platform library configuration.
There will always be a place for platform-native apps but cross-platform apps have different requirements. I don't care that my todo list application or IDE does not look exactly "native" on my Macbook. However I do care that these applications look and feel similar when I use them on my Macbook vs on my Linux machines or Windows laptop. Preferably without dragging in a full web-based rendering engine a la Electron.
> But if we drop this constraint and design widgets with their own consistent style within the same app
Style is just one of many things. And it's extremely hard to properly code your own consistent UI toolkit.
On top of that every platform has a myriad of platform-specific behaviors that people expect and that you will get wrong in yours. Accessibility is the big elephant in the room. But even things like secondary focus in prompts/dialogs on MacOS (that Apple's own Catalyst and Swift forget about) is a bitch and a half to get right.
Style is just one of many things. And it's extremely hard to properly code your own consistent UI toolkit.
On top of that every platform has a myriad of platform-specific behaviors that people expect and that you will get wrong in yours. Accessibility is the big elephant in the room. But even things like secondary focus in prompts/dialogs on MacOS (that Apple's own Catalyst and Swift forget about) is a bitch and a half to get right.
I agree, which is why I'm not advocating writing or designing your own toolkit. Instead we as a developer community should focus on the "next generation" of toolkits for the modern cross-platform world. Take all that we have learned from GTK, Qt, Flutter and all the web stuff and incorporate it into something new for the next 10-20 years.
Rust is a nice language for that since it is already a "next-generation" language in terms of memory safety and its momentum is still building. Projects like Druid, while far from ready, are a good starting point.
Rust is a nice language for that since it is already a "next-generation" language in terms of memory safety and its momentum is still building. Projects like Druid, while far from ready, are a good starting point.
The problem with this is unless you drag in something like Electron, you're inevitably going to end up using (or writing) something that just doesn't have the number of maintainers and quality development as either the native UI or an embedded webview. There's nothing with the level of development of e.g. Qt for Rust.
Which means "unsexy" things like accessibility get left by the wayside. And your users suffer.
Writing a UI kit is a huge task. It's one of those things (like so much else in our industry) where you can fairly quickly climb "stupid mountain" by getting a pile of shiny widgets on the screen; but then you look out over the valley below and realize that, holy, crap there's a whole other mountain range of things that a UI kit has to do.
It's also a tough story for Rust, in particular, because copying what other people have done with other toolkits won't really cut it. Rust's ownership semantics and general opinions don't necessarily accord well with the highly object oriented and event-loop / object-tree structure of most existing GUI toolkits.
Aside: I still don't understand why things like Electron based apps are so bloated. They seem to static link whole chunks of their own (forked) Chromium. But both Windows and Mac OS ship native webview components as part of their system which can be used instead. I've done this myself (used Edge's Chromium webview component in a VST synthesizer, and equiv webkit stuff on Mac) and binary sizes were entirely reasonable. Linux was a slightly more complicated story.
Which means "unsexy" things like accessibility get left by the wayside. And your users suffer.
Writing a UI kit is a huge task. It's one of those things (like so much else in our industry) where you can fairly quickly climb "stupid mountain" by getting a pile of shiny widgets on the screen; but then you look out over the valley below and realize that, holy, crap there's a whole other mountain range of things that a UI kit has to do.
It's also a tough story for Rust, in particular, because copying what other people have done with other toolkits won't really cut it. Rust's ownership semantics and general opinions don't necessarily accord well with the highly object oriented and event-loop / object-tree structure of most existing GUI toolkits.
Aside: I still don't understand why things like Electron based apps are so bloated. They seem to static link whole chunks of their own (forked) Chromium. But both Windows and Mac OS ship native webview components as part of their system which can be used instead. I've done this myself (used Edge's Chromium webview component in a VST synthesizer, and equiv webkit stuff on Mac) and binary sizes were entirely reasonable. Linux was a slightly more complicated story.
It's a tough story indeed, but every existing toolkit had to start from scratch at some point. If I'm not mistaken Druid had its start in 2017 (I personally contributed some stuff on the GTK bits around 2019) and it is far from ready but I see it progressing in the right direction. Accessibility is on its roadmap as well I believe.
This is why Rusts' "Are we GUI yet?" and posts like this are a good thing. Eventually some new toolkit will arise that ticks all the boxes. We are not there yet and it will require a huge amount of work.
This is why Rusts' "Are we GUI yet?" and posts like this are a good thing. Eventually some new toolkit will arise that ticks all the boxes. We are not there yet and it will require a huge amount of work.
There are plenty of apps written with Electron, which has styles far from "native" UI. But most people should not think of them as wrong.
There's this:
https://www.redox-os.org
https://www.redox-os.org
Shameless 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
Hey, I just ran the showcase locally. That looks super cool! Awesome project!
Thanks!
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
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
How many of those actually look and behave like native and support accessibility correctly?
What 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.
Win32, 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.
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.
Do you know which of those toolkits is used for the new Windows 11 Notepad? It's quite a bit more "laggy" to scroll in than the old Notepad that's still on the Server edition.
The old notepad was Win32, the new one is WinUI, there you have it, how good WinUI is in its current state.
https://www.thurrott.com/windows/windows-11/260092/hands-on-...
https://www.thurrott.com/windows/windows-11/260092/hands-on-...
Many of those are native enough, meaning they inherit the style from the desktop (and not just emulate it), do they support accessibility and so on.
For example, QtWidgets is native and qml is not. WxWidgets is, electron is not.
For example, QtWidgets is native and qml is not. WxWidgets is, electron is not.
Any of those will do as long as you don't drag in javascript crap.
This is a core design goal for Pax. https://www.pax-lang.org
Pax composites a layer of native text and form elements on top of a canvas drawing layer. This solves accessibility across platforms, as well SEO on the Web.
This approach also enables a lean runtime footprint (<100Kb, particularly useful when targeting Web) because the runtime doesn't need to reinvent text rendering, selection, input, etc.
Still early days — have made very little noise thus far; it's pre-alpha — but you can see what's cooking at https://docs.pax-lang.org/ and https://www.github.com/pax-lang/pax
Pax composites a layer of native text and form elements on top of a canvas drawing layer. This solves accessibility across platforms, as well SEO on the Web.
This approach also enables a lean runtime footprint (<100Kb, particularly useful when targeting Web) because the runtime doesn't need to reinvent text rendering, selection, input, etc.
Still early days — have made very little noise thus far; it's pre-alpha — but you can see what's cooking at https://docs.pax-lang.org/ and https://www.github.com/pax-lang/pax
It does not answer the native styling though…
Pax does solve this, but we're now discussing a different problem than element-level look-and-feel or accessibility. Three ways you can slice this with Pax, ft. pseudocode:
1. Conditional templating, like:
Or any mix of the above.
1. Conditional templating, like:
<SomeLayout>
if $is_android {
//Only render the back button for Android
<BackButton />
}
/* ... */
</SomeLayout>
<SomeElement some_property={self.get_platform_specific_value()} />
Or any mix of the above.
Does this actually render a native Android back button to the canvas or are you simply saying Pax solves this by not restricting the user from making their own solution to the problem?
Pax's Android chassis isn't built yet — but a Pax `<Button>` will render an actual native Android button to a layer on top of a separate canvas layer where vector drawing occurs.
That native Android button will be affine-transformed, clipped, and occluded so that the two layers together act as a single coherent screen, and the developer can simply position / transform / layout that `<Button>` alongside, on top of, or underneath virtual / drawn elements as if they were on the same canvas.
This "dual layer" approach is already implemented for Pax's `<Text>` element on macOS (native SwiftUI `Text`) and Web (native `<div>` + HTML text) — see: https://docs.pax-lang.org/intro-example.html
That native Android button will be affine-transformed, clipped, and occluded so that the two layers together act as a single coherent screen, and the developer can simply position / transform / layout that `<Button>` alongside, on top of, or underneath virtual / drawn elements as if they were on the same canvas.
This "dual layer" approach is already implemented for Pax's `<Text>` element on macOS (native SwiftUI `Text`) and Web (native `<div>` + HTML text) — see: https://docs.pax-lang.org/intro-example.html
This could be very interesting, I'll have to keep an eye on the development. Thanks!
With Slint [https://slint-ui.com], our aim is to achieve native look and feel, and accessibility.
Native doesn't really exist on desktops except macOS, but accessibility is a good question.
The native bindings are the first section on the list, and they work well. If you're concerned about looking and behaving native just use those native bindings.
The native toolkits, and Qt. Gtk if you're on Linux
None yet, but that is being worked on.
A 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/
[0]: https://github.com/bodil/vgtk/
FYI the project is called GTK, not GTK+, these days. They dropped it late in the 3.X cycle if I remember correctly.
Relm4 is similar.
https://relm4.org/
https://relm4.org/
Anyone 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.
Qt is the most mature system for running on a framebuffer.
I 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/
- [1] https://github.com/KDAB/cxx-qt/
Neat. Thanks!
That'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.
Flutter app with rust core works great too.
Yep, 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.
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.
Of 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.
One day I'll get around to finish my library Azul [1]. Hopefully.
[1] https://azul.rs/
[1] https://azul.rs/
Is there a decent immediate mode GUI for Rust? Think ImGui, I know of eGui but unsure how workable it actually is in reality.
I'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.
I 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.)
KAS 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.
This 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 .
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 .
QT 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.
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.
10 years ago Python was famous for how many web frameworks it had.
It seems Rust will be famous for the number of GUI libraries.
It seems Rust will be famous for the number of GUI libraries.
Why?
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.
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.
Oh, but Rust has even more web framework than GUIs libraries;).
wow, really impressive!
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.