pyfisch / keyboard-types

Types to define keyboard related events.
Apache License 2.0
54 stars 9 forks source link

Make this crate `no_std` #17

Open notgull opened 1 year ago

notgull commented 1 year ago

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.

pyfisch commented 1 year ago

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.

notgull commented 1 year ago

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.

pyfisch commented 1 year ago

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.

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.