I've done a small project with Dioxus on Blitz. It is principally very close to Xilem and in fact is using some of the Xilem components. https://github.com/DioxusLabs/blitz
Yes, we are collaborating closely with Linebender on Parley (the text engine) for which we have contributed a lot of code mostly for additional layout features (like the ability to layout images and other content inline with text).
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.
What's native about it? It seems like custom GPU rendered thingy with nothing "native".
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.
Indeed. I try not to use the word "native" these days as it has such ambiguous meaning. I also have thought for a while that Windows no longer has native UI, only legacy (Win32) and a rotating carousel of mostly-failed attempts. There have been a few HN stories in the last week that bear me out, notably [1]. Mac of course is in better shape, as AppKit and SwiftUI are both viable (and interop well enough).
It's a step forward. If someone makes an app which is some Electron/WebView thing and call it "native", my thoughts are immediately rather illegal. Cool, so it's UI framework that doesn't actually make a webpage presented as an app. Truly native for me means: using UI framework that is the gold standard for given OS, UX native for given OS, and using native OS APIs, so my laptop can actually survive 24h on battery. It's truly hilarious that Claude app (and ChatGPT) is just Electron app - argument that writing UI in Electron is cheaper is no longer valid in AI age, but yet they did it. Weird times.
I never said that. Ofc Qt apps work just fine on any desktop environment you have (or even none), but they still look off if run Qt app on Gnome. Looking off == not native.
Been using it with mixed success. While I love vello, Xilem is less mature in comparison. Many standard UI components, such as selection box, are not implemented yet. On the other hand, it’s a great opportunity to become a contributor towards a genuinely useful and promising project!
While I love seeing many alternatives regarding UI frameworks, I'd love to see one general purpose "market leader".
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)?
Is there any other lightweight UI Framework supporting software-rendering and framebuffer for embedded devices (RISC-V 64bit musl, LicheeRV Nano)?
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!
You might need to modify it slightly to get it to render to the right location, but it's a pure software renderer. You could ask in the Iced zulip https://iced.zulipchat.com/
I keep trying Xilem and then egui or Iced. Xilem needs more widgets out of the box to be easy to build with. Slint is another option. I wonder what cross platform GUI framework (from any language) will finally become as common as Electron based apps or the vast number of native OS apps in Windows or macOS or Linux.
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.
I wish it's that simple. Not all components are LGPL, so when you're doing LGPL and you suddenly need some must-have-but-not-LGPL component,you're in trouble.
I gave it a decent shot, and I wanted to like slint, but I don’t.
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.
Slint has nothing to do with elecron.
There is no browser under the hood so it is much more lightweight.
Slint has native looking widgets.
Slint DSL gets compiled to native code: no need for a runtime interpreter like in QtQuick
Something like GPUI probably, I would be quite happy with it if it wasn't so tied and restricted by the Zed's team (they reject PRs because they're not strictly related to Zed), there's even mobile fork.
Dioxus native would be second, but it's far far far away from being ready.
Not possible to do it via component. I've seen various, like custom user shaders or some silly basics like text justify (which is implemented in cosmic-text crate used by gpui). That's why it was forked.
The only things I don't like about this is a) your binaries will become huge and very slow to compile with optimizations enabled and b) it's dependence on GPUI and its unsure future direction (I'd like to see GPUI thrive outside of Zed but the maintainers have clarified that that's not the goal for now).
Was there some new developments with this project that renewed interest recently? I started learning Rust in 2018 or 2019 and I think "good Rust GUI" research is probably at least that old.
What's the rationale for using Rust to write a UI? Using a scripting language (or at least a garbage-collected language) is much less restrictive, and it's not like the "what goes where" UI code is especially performance-sensitive.
This is a perfectly reasonable question, and I think there are two aspects to it.
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.
Good thing about iced is, you get a compact executable, runs on any OS, looks exactly the same everywhere, perform much better than web based UI, no need to manage any permission to access local files, and you can customize the look as you need, but comes with tolerable default.
Price to pay is building the UI is bit complex as it doesn't hold your hand, unforgiving, and not native.
Very happy with qmetaobject-rs. Qt is tried and tested, dnd multi platform. Also, UI itself is best done declaratively not imperatively. Qmetaobject-rs gives you the best of both worlds: great UI declaratively, logic in Rust.
Given the similarity in "inspired by" projects, how does this compare to iced? I've found iced to be surprisingly mature in every aspect I've tried, except the documentation, which is severely lacking
Tested egui and it's great provided you accept the "immediate mode" and its limitations. It's quite polished nowadays although it misses in some areas.
91 comments
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.
[1]: https://news.ycombinator.com/item?id=47651703
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).
[0]: https://github.com/KDE/breeze-gtk
I said that Qt has a GTK theme. It doesn't, but KDE does have a GTK theme.
I love
icedfor its simplicity and flexibility, but unfortunately there is no official software renderer, which makes it impossible to use for my little embedded side project.Slintis 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)?
>
Is there any other lightweight UI Framework supporting software-rendering and framebuffer for embedded devices (RISC-V 64bit musl, LicheeRV Nano)?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!
If your interested, it is a portable audio player with the size of the iPod Nano 7g:
https://github.com/nanowave-player/nanowave-ui
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.
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.
> they reject PRs because they're not strictly related to Zed
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.
https://github.com/longbridge/gpui-component
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.
https://areweguiyet.com/
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.
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