I just attempted to write up a simple Minesweeper game with Iced. No bells or whistles, but it works:
https://github.com/veniamin-ilmer/minesweeper
On one hand, I find it pretty cool I built a clear cross platform GUI with actual functionality, within only 200 lines of code.
On the other hand, I can’t help but see how inefficient it seems. If I ever need to modify any of the objects, I need to redraw all of them. The structure of the view method makes me think it is very difficult for Iced to maintain a “virtual DOM” to only make delta changes.
Am I wrong? Is there a more efficient way to do this in Iced?
Edit: I just found this - https://github.com/iced-rs/iced/pull/1284
As the library matures, the need for some kind of persistent widget data (see #553) between view calls becomes more apparent (e.g. incremental rendering, animations, accessibility, etc.).
If we are going to end up having persistent widget data anyways… There is no reason to have impure, stateful widgets anymore!
So it seems like Iced plans to have an internal “persistent widget storage”, which in abstracted away from the user. But it is quite unclear to me how they would accomplish this, considering the view method doesn’t provide an ID for any of its objects, so it would not be easy for Iced to determine the difference between updates.
You must log in or # to comment.
As long as you store state in your application’s struct so that there’s no need to calculate and allocate in the view, then the view is quick to generate. You can also use lazy widgets that will avoid being re-recreated unless a given input has changed. Have you benchmarked to compare? You’d be surprised how efficient it is compared to heavier frameworks like GTK.
Have you looked at Bevy before? There is a popular Rust YouTuber that posts videos of his Bevy projects. Definitely look there for inspiration.
Bevy is awesome, but I don’t think it’s really designed to be used as a retained-mode UI framework. I know it’s on their roadmap to support traditional UIs (or at least was at one point), but as it is right now, it’s primarily useful for making games which require regular re-renders of the entire screen.
Care to say who they are?
Tantandev
The main issue I’ve come across experimenting with Rust UI frameworks is that none of them seem to have a decent multiline / rich text field story. Iced and the like are nice for simple apps but if you need to e.g. input Markdown and render it nicely all in one field you’re out in the wilderness.
Indeed, a lacking multiline text is what stopped me from trying to use it as well. But with the minesweeper example, I thought “it’s just a bunch of buttons, surely this is simple enough for me to build?”
But no, the button widget doesn’t support right clicks or double clicks, which limits the functionality I can build into minesweeper.
Overall, I love how simple Iced code ends up being, which makes me think about contributing to this project. Only issue I have with it is this seeming inefficiency.
That’s been resolved by cosmic-text, which is being used by iced now. The cosmic-text crate provides a text editing widget, too.
Is it actually ready to use? I don’t see much information about how to use it. I know there’s been work on integrating cosmic-text, but I notice this issue is still open: https://github.com/iced-rs/iced/issues/320
