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.
The way Vello/Masonry/Xilem are split projects is partially what got me interested in it (and in turn caused me to post it to HN), as well as the reactive architecture of Xilem.
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.
I have been watching people write UI frameworks in Rust for over a decade, you meanie.
The results tend to involve more dynamic allocation than you'd see in a garbage-collected language, or tons of reference counting (e.g., in Leptos) that acts as a less efficient GC. I've read many of raphlinus's posts, and while they're always interesting, the total experience in the Xilem examples just seems like much more effort than using FFI (even C FFI) to glue to something more workable.
Your comparison to assembly is very bizarre - languages of the sort I mentioned are usually at least as safe as Rust, and the "scripting language for top-level logic + compiled language for the bits that need to be fast" combination is ancient. In fact, your vague allusions to "a stable base, without infinite danger everywhere" shows much less understanding of what's at stake, in my view.
I'm sorry my question wasn't enlightened enough for you.
And this is a news aggregator. Not the official discussion forums or anything. People can ask small insignificant questions here, or so I thought.
I'm so tired. You write one measly paragraph that could simply be ignored and someone calls you a "perpetuate drain". Even the chatbots have more humanity than you've got.
> I'm so tired. You write one measly paragraph that could simply be ignored and someone calls you a "perpetuate drain". Even the chatbots have more humanity than you've got.
Don't tire everyone else out by asking open ended draining questions. Show some engagement, before doing what looks like a discarding.
You've shown you have some interest or connection to the situation, with your reply. None of that was present before, in your 'just-asking-questions' "measely paragraph". It looked like just another anti-rust anti-systemd anti-pipewire/pulseaudio anti-wayland drain, only sapping energies without showing faintest attempts at engaging. Offer something, try to have some positive sum.
We are all so tired. Why be a vacuum, why drain us, like you did? Critical review is fine! But show some engagement, offer something yourself, when doing so.
> Don't tire everyone else out by asking open ended draining questions
What are you on about? If you're so tired, don't put it on yourself to answer these "open ended draining questions". Internet continues to work the same way as before, anyone writes whatever they feel like, others engage, if you don't want, don't. But it's not up to you what questions are acceptable or not, what kind of world view is that?
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.
Iced is the clear number one for me, too. The only thing I'd love to see officially supported in iced in the future is mobile apps. But it looks like that ain't gonna happen anytime soon (with the most recent PRs getting rejected once again).
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.
Hm, I believe my wording is bit unclear. The trait system can really get complex as your widget layout gets more complex, and you want to write reusable components, But there's no clear way to understand what's the type it's expecting from the errors. You need to really understand the traits to implement any reusable components. Which is why I felt it's kind of unforgiving, if you're not fully knowledgeable of the primitives.
But I'm still learning it, so, probably missing some details.
