-
Notifications
You must be signed in to change notification settings - Fork 13
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-F35
variants onCode
andKey
- 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
Modifiers
at some point? (e.g.LALT
/RALT
,LCTRL
/RCTRL
, ...) -
winit
has a bit of a different serialization logic forModifiers
- We enrich the
Unidentified
key code to allow access to the raw platform-specific scancode. -
Meta
vs.Super
is confusing, could perhaps be merged into a single thing? Fixed by AlignNamedKey
andKeyCode
more closely with the W3C specs winit#4018. -
Key::Character(String)
is harder tomatch
on 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
-
winit
hasKey::Dead(Option<char>)
to allow specify the character which is inserted when pressing the dead-key twice -
Key::Space
is 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
.