rust-windowing
Make this crate `no_std`
This crate currently relies on libstd; however, I'd like to use this in a no_std program. Looking through the source code, it looks like the only std-exclusive import this uses (without additional features) is Error. If we made this optional, this crate could be used in no_std environments. This would be a breaking change.
In addition, it may also be a good idea to also eliminate the dependency on liballoc. Right now String is used in Key, but it may be replaced by an &'a str in order to allow usage on platforms without allocators and eliminate a potential allocation from the crate.
I will implement this PR if the behavior is desired.
If we made this optional, this crate could be used in no_std environments.
This crate is primarily used by servo and high-level GUI tool-kits. Both depend on the standard library. What is your use-case for this crate in a no_std environment?
In addition, it may also be a good idea to also eliminate the dependency on liballoc. Right now String is used in Key, but it may be replaced by an &'a str in order to allow usage on platforms without allocators and eliminate a potential allocation from the crate.
Wouldn't make that the crate more complicated to use in general? I'm not convinced that the allocation has a measurable performance impact.
What is your use-case for this crate in a no_std environment?
I'm creating an experimental lightweight no_std toolkit, where the library is welded directly to winuser or libxcb without the standard library being involved.
What is your use-case for this crate in a no_std environment?
I'm creating an experimental lightweight
no_stdtoolkit, where the library is welded directly to winuser or libxcb without the standard library being involved.
Ok. I personally don't think that GUI applications gain much from avoiding the standard library. When your toolkit reaches the point where its used in applications I will reevaluate if keyboard-types should support operation without std. Then I might merge your patch.