-
Notifications
You must be signed in to change notification settings - Fork 17
Integration with winit #19
Description
Greetings @pyfisch!
I see that you've previously helped out a lot in pushing winit forwards on better keyboard handling (though this was before my own time as maintainer though, so we haven't really interacted, and I'm quite out of the loop on it, do say so if I'm mistaken about something!)
We've recently come closer to finishing that age-old work, see rust-windowing/winit#2662 (comment) - after that, it would be nice to try to consolidate winit's needs for keyboard types with this crate's types.
I see that you've proposed merging things before in rust-windowing/winit#753 (comment), and have created the branch winit to do some of this work already, is this still something you would be interested in helping out with?
Doing a quick diff between the implementations reveal:
- Missing
F25-F35variants onCodeandKey - We might want to support letting the user know if the left vs. right modifier key is being held; is this something you be open to support on
Modifiersat some point? (e.g.LALT/RALT,LCTRL/RCTRL, ...) -
winithas a bit of a different serialization logic forModifiers - We enrich the
Unidentifiedkey code to allow access to the raw platform-specific scancode. -
Metavs.Superis confusing, could perhaps be merged into a single thing? Fixed by AlignNamedKeyandKeyCodemore closely with the W3C specs winit#4018. -
Key::Character(String)is harder tomatchon than e.g.&str, and may be more inefficient than e.g.Cow<'static, str>.- Unsure about this one, I know @maroider has some thoughts on this, and that has also been discussed at length
-
winithasKey::Dead(Option<char>)to allow specify the character which is inserted when pressing the dead-key twice -
Key::Spaceis missing, though perhapsKey::Character(" ")is indeed cleaner - We try to follow a MSRV-policy of "works with ~7 months-old Rust versions", would you be willing to try to adhere to that as well (as a minimum)?
A proposed solution there was adding an extension parameter to KeyboardEvent, Key and Code like this:
enum Code<Extra = !> {
// ...
Extra(Extra),
}
enum Key<Extra = !> {
// ...
Extra(Extra),
}
struct KeyboardEvent<Extra = ()> {
// ...
pub extra: Extra,
}Along with a method like without_extra that discards any extra data.
That would allow us to keep the ergonomics higher than matching on e.g. WinitCode { code: Code::Backquote, .. }.
Relatedly, it would also be nice to use your CompositionEvent, for this we may need to specify a cursor along with that - so next time you're doing a breaking release, might want to consider #[non_exhaustive] on that too - but let's focus on Key, Code and KeyboardEvent.