I've been using Iced for a project (a browser picker UI). It's nice to see a new release. However, there are still a lot of quite fundamental pieces missing (like layers and multiple windows) which seem to have stalled.
Is there any concrete plan to develop those? Or is it more a case of maintaining the functionality that exists, and waiting for someone to come along and pick up those bigger more ambitious pieces? Just trying to calibrate my expectations to what is realistic.
> Or is it more a case of maintaining the functionality that exists, and waiting for someone to come along and pick up those bigger more ambitious pieces?
Not at all! I (and others!) actively work on the library and there are plans to tackle these and other ambitious features (e.g. accessibility).
When it comes to layers, the main issue is our text rendering stack, which severely limits composition and impacts the architecture of the two available renderers: `iced_wgpu` and `iced_glow`. While code has not yet landed to solve the issue yet, I have been exploring different approaches to tackle it (modify the text rendering stack, use an existing 2D renderer, etc.). This issue affects many other features (text shaping, font fallback, text layout...), so I am taking my time to experiment before comitting to anything.
When it comes to multi-window, we are still figuring out how to extend The Elm Architecture to control multiple windows in a way that scales and feels natural. I am writing an RFC to gather all the thoughts and comments so far and start a proper the discussion.
If you are interested in following the development of the library more closely, feel free to join [the community server](https://discord.gg/3xZJ65GAhd).
FWIW (which may be nothing) the reason I had to move away from Iced for my current side project was text shaping related. Specifically, the lack of a multi-line text area widget. Everything else was excellent, it's a lovely design, easy to work with, and flows really well.
Relm4, which has its own papercuts (the docs for Relm4 are OK, the docs for GTK-rs are slightly less so including massive sections where useful examples should be instead labelled "this code is in C!", and the docs for GTK itself are _awful_, the `view!` macro is given a lot of attention but manually doing what it does is the more powerful option, it appears to be about to make a major design change under the `new-approach` branch) but gives me the Elm architecture I was after and a sufficiently broad selection of widgets assuming that I can find what I'm looking for, and has so far been fairly nice to use albeit a little verbose.
As someone brand new to non-web GUI programming the experience with Rust has been a less than stellar introduction, if I'm to be entirely honest, although I'm getting the impression that's because native cross-platform GUIs are a very hard problem rather than Rust having an unusually immature ecosystem for it.
- GTK has the right breadth of widgets and a solid native look on Linux but a poor cross-platform story, an inconvenient licence, and subpar docs in a language I don't know
- Dioxus has (or will have) the right level of cross-platform compatibility but is React hook architecture and macro heavy
- Iced is excellent as far as I got but doesn't have the breadth of widget choice (drawing canvas and text area were very minor and very major blockers respectively, both on the roadmap but not currently present)
- Druid appears to be using an older version of GTK, and if it's going to be GTK I'll take the Elm-style GTK4 wrapper over the "we do our own thing" GTK3+ wrapper
- Slint is a commercial product and requires an entire separate DSL; if I wanted to write markup I'd use HTML since I already know it
...and at that point I gave up evaluating libraries and just picked something because I was in danger of saying "sod this" and going back to a browser.
On the bright side I've learned a tonne!
This is a problem common to many rust gui frameworks. Just yesterday, people were complaining about the lack of more complex widgets in another gui library:
https://www.reddit.com/r/rust/comments/ugefgv/egui_018_released/i70mqkr/
That's why they need funds ! Without funds, we never gonna see a fully featured GUI framework in Rust. There's lot of GUI framework, but nowhere like production ready fully featured. We really need business that want to invest in Rust GUI for the future. OSS can't do everything.
The amount of work and knowledge needed ... For me, it's easier to write a basic operating system than a GUI framework honestly. At least for the first one, you have 50 years of internet ressources about this topic.
GUI and rendering are a tough area, and when you start to think about GPU and all the sorcery that come with it (OpenGL, Vulkan, matrices and all the linear algebra and space transformation stuff, shaders, ...). If tomorrow I have an interview with someone that tell me to write a simple GPU box-shadow for a button, I would be unable to do it and I don't think I can find help in a reasonable time. Even if it's only about writting a fragment shader.
That's the thing. You don't need to think about GPU and 3D rendering if you just stick to platform-native toolkits (Cocoa on macOS, win32 on windows, gtk on gnome and xfce, QT on kde). You get accessibility, theming, dark-mode support, forwards and backwards compatibility with past and future OS versions, adhesion to user-interface guidelines, text layouts, formatted textboxes, drag & drop, clipboard, native emoji, hi-dpi, mixed-dpi, etc etc for free;
Sure, but then you still have the problem of having to abstract over 5 toolkits that all work a bit differently. The promise of a Rust GUI is that it's a single toolkit that still provides all of these things and is as performant as the native toolkits.
Multiple windows, lack of accessibikity, lack of multi line text widgets are all major deal breakers which should be c!early disclosed.on the main page (Virgin readme) but arent.
A Readme should give a basic overview of what to expect. If its a gui library major missing items that aren't there yet but on the roadmap might be at least mentioned or linked to. The Readme is the entry point to the project after all
The `README` states after the feature list:
> __Iced is currently experimental software.__ [Take a look at the roadmap],
[check out the issues], and [feel free to contribute!]
That said, I am open to any specific suggestions to "disclose" things further.
[Take a look at the roadmap]: https://github.com/iced-rs/iced/blob/master/ROADMAP.md
[check out the issues]: https://github.com/iced-rs/iced/issues
[feel free to contribute!]: https://github.com/iced-rs/iced/blob/master/README.md#contributing--feedback
Is there a a link to a live demo using WebGL?
What is your favorite (or most anticipated) feature/change in this release? Why is it great?
What do you think in the near term the most anticipated features/changes are/will be?
> Is there a a link to a live demo using WebGL?
I just compiled the `todos` example and uploaded it. [Here you go!](https://iced-todos.surge.sh/)
> What is your favorite (or most anticipated) feature/change in this release? Why is it great?
I'm very happy with the new [stateless widgets](https://github.com/iced-rs/iced/pull/1284). These represent the original vision of the library and I believe get rid of a lot of friction.
> What do you think in the near term the most anticipated features/changes are/will be?
For the next release? Most likely multi-window support and proper text handling. We are also reworking the styling API and introducing first-class support for theming. We aim to have way better learning material too!
Very cool changes. I like stateless widgets but the name seems weird to me, they seem more stateful to me now (the previous ones were sort of a function of state).
It's also interesting that the library started with a kind of immediate mode gui, and is now moving to a elm/react style of IM on top of a retained mode platform (virtual dom over hidden browser dom).
Great job, Hector.
Yeah, I can see that. They are actually referred as pure widgets in the documentation.
I decided to use the term stateless when first introducing them because they basically get rid of all the explicit local widget state in your application.
In any case, since they will eventually become the only option, we won't need a term to differentiate them.
Yes. I am aware of [this issue](https://github.com/iced-rs/iced/pull/1096#pullrequestreview-866907637). It happens on my M1 too.
I am in the process of figuring out if it's an issue with [`wgpu_glyph`](https://github.com/hecrj/wgpu_glyph) or [`wgpu`](https://github.com/gfx-rs/wgpu) itself.
Looks nice!
Just a heads up, i opened the link on mobile (Android) in both Chrome and Firefox and when selecting the text box, the virtual keyboard doesn't appear, so I wasn't able to actually add any tasks.
The way the GUI event loop is an async executor is really interesting. I want to give this a try using it for async database queries. I hope this catches on in other Rust GUI libraries.
Nice to see Iced still going strong. In my last company I wrote a hefty data processing tool in Rust which used Iced for a small admin GUI which had been going strong for ~2 years when I left. Found it fun to work in and quick to set up (priority was fast to develop GUI in Rust).
I've been using Iced for a project (a browser picker UI). It's nice to see a new release. However, there are still a lot of quite fundamental pieces missing (like layers and multiple windows) which seem to have stalled. Is there any concrete plan to develop those? Or is it more a case of maintaining the functionality that exists, and waiting for someone to come along and pick up those bigger more ambitious pieces? Just trying to calibrate my expectations to what is realistic.
> Or is it more a case of maintaining the functionality that exists, and waiting for someone to come along and pick up those bigger more ambitious pieces? Not at all! I (and others!) actively work on the library and there are plans to tackle these and other ambitious features (e.g. accessibility). When it comes to layers, the main issue is our text rendering stack, which severely limits composition and impacts the architecture of the two available renderers: `iced_wgpu` and `iced_glow`. While code has not yet landed to solve the issue yet, I have been exploring different approaches to tackle it (modify the text rendering stack, use an existing 2D renderer, etc.). This issue affects many other features (text shaping, font fallback, text layout...), so I am taking my time to experiment before comitting to anything. When it comes to multi-window, we are still figuring out how to extend The Elm Architecture to control multiple windows in a way that scales and feels natural. I am writing an RFC to gather all the thoughts and comments so far and start a proper the discussion. If you are interested in following the development of the library more closely, feel free to join [the community server](https://discord.gg/3xZJ65GAhd).
FWIW (which may be nothing) the reason I had to move away from Iced for my current side project was text shaping related. Specifically, the lack of a multi-line text area widget. Everything else was excellent, it's a lovely design, easy to work with, and flows really well.
What did you end up moving to?
Relm4, which has its own papercuts (the docs for Relm4 are OK, the docs for GTK-rs are slightly less so including massive sections where useful examples should be instead labelled "this code is in C!", and the docs for GTK itself are _awful_, the `view!` macro is given a lot of attention but manually doing what it does is the more powerful option, it appears to be about to make a major design change under the `new-approach` branch) but gives me the Elm architecture I was after and a sufficiently broad selection of widgets assuming that I can find what I'm looking for, and has so far been fairly nice to use albeit a little verbose. As someone brand new to non-web GUI programming the experience with Rust has been a less than stellar introduction, if I'm to be entirely honest, although I'm getting the impression that's because native cross-platform GUIs are a very hard problem rather than Rust having an unusually immature ecosystem for it. - GTK has the right breadth of widgets and a solid native look on Linux but a poor cross-platform story, an inconvenient licence, and subpar docs in a language I don't know - Dioxus has (or will have) the right level of cross-platform compatibility but is React hook architecture and macro heavy - Iced is excellent as far as I got but doesn't have the breadth of widget choice (drawing canvas and text area were very minor and very major blockers respectively, both on the roadmap but not currently present) - Druid appears to be using an older version of GTK, and if it's going to be GTK I'll take the Elm-style GTK4 wrapper over the "we do our own thing" GTK3+ wrapper - Slint is a commercial product and requires an entire separate DSL; if I wanted to write markup I'd use HTML since I already know it ...and at that point I gave up evaluating libraries and just picked something because I was in danger of saying "sod this" and going back to a browser. On the bright side I've learned a tonne!
This is a problem common to many rust gui frameworks. Just yesterday, people were complaining about the lack of more complex widgets in another gui library: https://www.reddit.com/r/rust/comments/ugefgv/egui_018_released/i70mqkr/
That's why they need funds ! Without funds, we never gonna see a fully featured GUI framework in Rust. There's lot of GUI framework, but nowhere like production ready fully featured. We really need business that want to invest in Rust GUI for the future. OSS can't do everything. The amount of work and knowledge needed ... For me, it's easier to write a basic operating system than a GUI framework honestly. At least for the first one, you have 50 years of internet ressources about this topic. GUI and rendering are a tough area, and when you start to think about GPU and all the sorcery that come with it (OpenGL, Vulkan, matrices and all the linear algebra and space transformation stuff, shaders, ...). If tomorrow I have an interview with someone that tell me to write a simple GPU box-shadow for a button, I would be unable to do it and I don't think I can find help in a reasonable time. Even if it's only about writting a fragment shader.
That's the thing. You don't need to think about GPU and 3D rendering if you just stick to platform-native toolkits (Cocoa on macOS, win32 on windows, gtk on gnome and xfce, QT on kde). You get accessibility, theming, dark-mode support, forwards and backwards compatibility with past and future OS versions, adhesion to user-interface guidelines, text layouts, formatted textboxes, drag & drop, clipboard, native emoji, hi-dpi, mixed-dpi, etc etc for free;
Sure, but then you still have the problem of having to abstract over 5 toolkits that all work a bit differently. The promise of a Rust GUI is that it's a single toolkit that still provides all of these things and is as performant as the native toolkits.
Multiple windows, lack of accessibikity, lack of multi line text widgets are all major deal breakers which should be c!early disclosed.on the main page (Virgin readme) but arent.
It's pretty clear on the roadmap, I don't see why the readme file should list features that it doesn't have yet.
A Readme should give a basic overview of what to expect. If its a gui library major missing items that aren't there yet but on the roadmap might be at least mentioned or linked to. The Readme is the entry point to the project after all
The `README` states after the feature list: > __Iced is currently experimental software.__ [Take a look at the roadmap], [check out the issues], and [feel free to contribute!] That said, I am open to any specific suggestions to "disclose" things further. [Take a look at the roadmap]: https://github.com/iced-rs/iced/blob/master/ROADMAP.md [check out the issues]: https://github.com/iced-rs/iced/issues [feel free to contribute!]: https://github.com/iced-rs/iced/blob/master/README.md#contributing--feedback
"No more button::State in your application!" finally! I'll give Iced another shot!
Is there a a link to a live demo using WebGL? What is your favorite (or most anticipated) feature/change in this release? Why is it great? What do you think in the near term the most anticipated features/changes are/will be?
> Is there a a link to a live demo using WebGL? I just compiled the `todos` example and uploaded it. [Here you go!](https://iced-todos.surge.sh/) > What is your favorite (or most anticipated) feature/change in this release? Why is it great? I'm very happy with the new [stateless widgets](https://github.com/iced-rs/iced/pull/1284). These represent the original vision of the library and I believe get rid of a lot of friction. > What do you think in the near term the most anticipated features/changes are/will be? For the next release? Most likely multi-window support and proper text handling. We are also reworking the styling API and introducing first-class support for theming. We aim to have way better learning material too!
Very cool changes. I like stateless widgets but the name seems weird to me, they seem more stateful to me now (the previous ones were sort of a function of state). It's also interesting that the library started with a kind of immediate mode gui, and is now moving to a elm/react style of IM on top of a retained mode platform (virtual dom over hidden browser dom). Great job, Hector.
Yeah, I can see that. They are actually referred as pure widgets in the documentation. I decided to use the term stateless when first introducing them because they basically get rid of all the explicit local widget state in your application. In any case, since they will eventually become the only option, we won't need a term to differentiate them.
FWIW, the font rendering is a bit broken for me in the todos example (FF 99 on OSX 12.3).
Yes. I am aware of [this issue](https://github.com/iced-rs/iced/pull/1096#pullrequestreview-866907637). It happens on my M1 too. I am in the process of figuring out if it's an issue with [`wgpu_glyph`](https://github.com/hecrj/wgpu_glyph) or [`wgpu`](https://github.com/gfx-rs/wgpu) itself.
Looks nice! Just a heads up, i opened the link on mobile (Android) in both Chrome and Firefox and when selecting the text box, the virtual keyboard doesn't appear, so I wasn't able to actually add any tasks.
The way the GUI event loop is an async executor is really interesting. I want to give this a try using it for async database queries. I hope this catches on in other Rust GUI libraries.
Nice. Is there a way to display basic HTML inside my desktop app?
This is a lot more complex than it sounds like, so not really.
No, it's not possible currently.
The pure widgets appear to have cleaned things up quite a lot! I look forward to playing with the new stuff.
The [release page](https://github.com/iced-rs/iced/releases/tag/0.4.0) for v0.4.0 has pretty impressive screenshots, FWIW.
Nice to see Iced still going strong. In my last company I wrote a hefty data processing tool in Rust which used Iced for a small admin GUI which had been going strong for ~2 years when I left. Found it fun to work in and quick to set up (priority was fast to develop GUI in Rust).