search

emilk / egui

egui: an easy-to-use immediate mode GUI in Rust that runs on both web and native
https://www.egui.rs/
Apache License 2.0
21.7k stars 1.56k forks source link

no-std Support #2755

Closed camblomquist closed 1 year ago

camblomquist commented 1 year ago

A bout of hyperfocus lead me to question why egui wasn't no-std compatible regardless of its practicality. Nobody seems to have asked for this and maybe this is silly and doesn't make any sense.

Digging through the required parts of egui and epaint, HashTable appears to be the only thing coming from std that isn't available in core or alloc. Hashbrown fills the equivalent role for no-std environments. Use of hashbrown should also allow the removal of the std feature from ahash.

The other question of course is how a backend would be no-std. embedded-graphics seems like a suitable candidate for constructing an egui backend. Or maybe I once again misinterpret the situation. Implementing the backend I suppose ends up being the task of whomever actually needs a no-std egui, I just wanted to make the point that it appears possible.

Now it's certainly possible that I'm missing something that would make the minimal feature set of egui more difficult to make no-std. It's certainly possible that even if this made sense to do it, nobody would actually use it and just rely on embedded-graphics directly. I just needed to put the thoughts into words and maybe someone will stumble upon this someday when asking the same question.

notgull commented 1 year ago

+1'ing this issue. There's no reason why the egui core couldn't be no_std.

emilk commented 1 year ago

I've never done any no_std work, so I'll take your word for it.

Is there any need for no_std egui, or is this just a philosophical point? :)

camblomquist commented 1 year ago

When I had initially proposed it I had a specific project in mind but I am actually not sure if said project would actually benefit from egui at all (the interface for this project would have assumed physical buttons for soft keys or a touch screen and I imagine that most embedded projects would be in a similar boat.) Regardless, that project is no longer relevant.

Since nobody else has requested it and "no reason why not" doesn't serve much justification, I don't think there is a current need for it if any need at all.

For now I'm fine with closing the issue. In some future where someone else actually needs it and assuming things haven't changed to the point where a no_std implementation is impractical, I'd be willing to lay the groundwork to make it happen. It's probably for the best to wait until a point where the interfaces are no longer in flux but I don't know enough about library or no_std development to say that for certain.

David-OConnor commented 1 year ago

I would use this.

theoparis commented 2 months ago

I would use this.

Same here.