Xilem – An experimental Rust native UI framework
github.com
github.com
And slightly less closely on the Vello renderers for which we haven't directly contributed much code, but which we support as backends for Blitz which we have used to help with validation and testing.
Linux GUI frameworks are hot potato, I tried to write "native-feeling" app with taskbar icon lately on Linux (Cinnamon), intuition says GTK3, Internet says GTK4. Cinnamon says write it in JS and plug it in as an applet. Qt seems like the most complete GUI framework, but I don't like KDE (and Qt on mostly GTK based env looks weird). Windows is the same, Microsoft has like 10 different UI frameworks from different epochs. MacOS seems to be the only one with some common UI framework.
On Linux you're right to say it's basically choosing between gtk and qt.
And IIRC Qt has a GTK theme nowadays that makes it look not terrible (high praise, I know).
I said that Qt has a GTK theme. It doesn't, but KDE does have a GTK theme.
I love `iced` for its simplicity and flexibility, but unfortunately there is no official software renderer, which makes it impossible to use for my little embedded side project.
`Slint` is also usable, however I'm not sure about the licensing approach that makes you pay for non open source projects (which is totally understandable, but somehow this feels like a no-go for the "leading" UI framework). The Slint UI DSL feels very good at first, but the more you use it, the more you run into limitations like missing async support for callbacks, the lack of importing structs from Rust into and export UI structs to Rust, etc. However, it at least supports a software renderer and framebuffer.
Is there any other lightweight UI Framework supporting software-rendering and framebuffer for embedded devices (RISC-V 64bit musl, LicheeRV Nano)?
If your interested, it is a portable audio player with the size of the iPod Nano 7g:
There's no crates.io release yet, but the master branch of Xilem and Masonry is somewhat renderer-agnostic, and lets you use vello_cpu, which does SIMD-assisted software rendering (I don't know how good the RISC-V support is).
I say "somewhat" because it's supported by the internals crates (xilem_masonry, masonry_core), but not by the composition root crate (xilem), so you have to implement your own integration with winit, but we're getting there!
I keep going back to Tauri, which is practical to build desktop apps quickly but still uses HTML, CSS, JS to build the UI. You can use Rust web UI tools but then it is still (system) browser based.
Unless you were talking about commercial licenses - in that it's not that complicated neither; it's expensive.
What kind of PRs? Like new widget components or what?
Maybe https://github.com/longbridge/gpui-component would be more keen on accepting PRs like that?
So there is now a fork: https://github.com/gpui-ce/gpui-ce/ But I don't know if that's sustainable.
I hope the community fork could gain traction. I believe there's a lot of potential in GPUI.
It’s not a rust ui system; it’s a declarative ui language that happens to have a rust binding via macros so you can write the custom DSL.
It also has bindings for other languages.
It feels like a bunch of qtquick people got together and implemented a new runtime for qtquick. That might be the direction qt has gone, at the expense of their c++ qtwigets system, but it just feels… “electron app” to me.
If I wanted an electron app, I would just use electron.
If I wanted a non-native ui look and feel, I would use flutter.
Failed to open window: WebGPU context not initialized. Was Platform::run() called?
Not being able to load the component gallery does not inspire great confidence.
It's not really designed for the web though so I wouldn't hold that against it.
And you don't need to ship the entire web stack just to get GUI.
Price to pay is building the UI is bit complex as it doesn't hold your hand, unforgiving, and not native.
I like iced. But tauri is good middle ground
But I'm still learning it, so, probably missing some details.
I can focus just fine. I want to detect if a text_input is focused, when I am checking key-presses.
But going through every discussion and all, there was a PR that might have allowed to do this, and it's been merged, but it's not working the way I want.
My use case is, If the text_input is not focused, I can press characters to perform some operations. If text_input is selected, it should be ignored.
For now I am back using modifiers, will get back to this later.
First, one of the research questions tested by Xilem is whether it is practical to write UI in Rust. It's plausible that scripting languages do end up being better, but we don't really know that until we've explored the question more deeply. And there are other very interesting explorations of this question, including Dioxus and Leptos.
Second, even if scripting languages do turn out to be better at expressing UI design and interaction (something I find plausible, though not yet settled), it's very compelling to have a high performance UI engine under a scriptable layer. I've done some experiments with Python bindings, and I think in an alternate universe you'd have apps like ComfyUI as high performance desktop app rather than a web page. Also, the layering of Xilem as the reactive layer, backed by Masonry as the widgets, is explicitly designed to be amenable to scripting, though to my knowledge there hasn't been a lot of actual work on this.
I do believe a garbage collected interpreted language would work best for UIs. Something like Vala (for gtk) but with a runtime/vm.
python-qt has shown to be a very strong combination. My issue with such solutions is that packaging a python application to the end-user can bloat binary size.
I also think GTK should get some credit in that space, because due to GObject introspection it's easy to interface with GTK with any language.
ImHex is a great hex editor, lots of features. It’s got antialiased fonts like only a year ago. Fonts still look not exactly as the rest of the OS. Has no accessibility integration at all.
Zed, looks pretty good at first glance. No accessibility.
“Native” implies all the features that the platform provides. It is chaotic on all major platofrms but it’s still meaningful.
Why is this still a talking point? So what if the app renders with AppKit or Cairo on macOS, you can both look as native as the other, doesn't the actual UX matter more than how the implementation was made?
An Electron app that draws all its components mostly like the native controls will still not be native and have the same integrations etc. that native apps usually get.
You could get close but some things like for example "ctrl+f" search have native widgets that work different/look different that an electron app realistically won't have. Or for example you will never get the same liquid glass materials that macOS uses in an electron app.
So yea, native in my books means using the platform native (UI) apis. On Ubuntu for examples thats GTK, on Windows its.... idk at this point, WinUI? and on KDE it would be Qt.
Again I don't understand the obsession with caring so deeply about the implementation, as long as the end results are the same, why it matters so much?
Take my Liquid Glass for example, you simply won't be able to match the look in an electron app in practice.
Ofc if the result is the same it doesn't matter how, but in reality it's almost impossible to imitate the look and capabilities since it would require a Herculean effort to keep feature parity.
Yes, this is what we want.
an application could be implemented with Objective-C and/or Swift but not use Cacoa/AppKit/SwiftUI APIs, then that's not an native application
Correct. The toolkit matters, not the language. Native toolkits have very rich and subtle behavior that cannot be properly emulated. They also have a lot of features (someone mentioned input methods and accessibility) that wrappers or wannabe toolkits often lack. To get somewhat back on topic I notice and appreciate that Xilem mentions accessibility.
games written with Vulkan/OpenGL aren't "as native"...
Games are usually fullscreen and look nothing like desktop apps anyway so it doesn't matter what API they use.
I joke, but probably rustdesk is so glued together, it created that bad impression on me.
Try Xilem if you want to experiment with new, experimental way to build UIs in Rust.
It does support the modern 2D imaging model. It is in transition from using "Vello GPU" (aka Vello Classic) to the understory imaging abstraction, which means it can use any competent 2D renderer, including Skia.
Xilem is more like Iced but with it's own patterns and underlying graphics library.