Iced: Is no-std in-scope of this project?

[ghost]

I am looking to implement an embedded UI, so I could port a no-std compatible core to a render backend, if that is in line with the project. Just asking.

[hecrj]

I think the library is currently at a point where fast prototyping and easy exploration are key. We are just starting out and everything will likely change considerably as we try to satisfy more use cases. Supporting no_std at this point could make this harder.

In my opinion, we should currently focus on writing a great library for building native UIs. This is quite a challenge already, and it will bring a lot of value if we succeed.

That said, I believe no_std would be a nice addition once the different APIs stabilize:

1. iced_core will probably be the crate to get a stable API first. It should remain fairly simple, so we may be able to add no_std support without much of a hassle.
2. From there, we could consider adding no_std support to iced_native. This will be harder, as it will most likely grow to be quite a complex runtime. If this is not feasible, a simpler runtime could be built for no_std instead.
3. Then, it would be a matter of writing a no_std renderer for iced_native or the new no_std runtime (or adding support to an existing one).

My experience with no_std is quite limited, so any help here will be greatly appreciated. I am aware that building a library without no_std in mind can make it much harder to support it in the future. What are the most common blockers when adding no_std support to a library?

[ghost]

What are the most common blockers when adding no_std support to a library?

Using OS primitives, like files, unix sockets, executor, etc. depedencies in the core. So state (database), executor and IO (messages, networking) are two big ones which usually use the OS facilities. Async/await is currently unable to satisfy no_std for exemple since it uses 'thread local storage' to hold some future-related state, but lots of us are interested in overcoming this. Like you said, the more limited the scope the easier it is.

The currently best attractive backend for my project is here:
https://github.com/jamwaffles/embedded-graphics
The emulator uses SDL2 for rendering. My first prototype targets a very small e-ink display.

It is quite crude, so sophisticated graphics are out of the question. But my main goal is to create a declarative UI DSL, like elm, for a very simple GUI. Hence my very early inquiry into iced. The runtime has to eventually fit in half a MByte, ideally. I'll take a look at iced_core. Thanks for your response.