Skip to content

Integration with winit #19

@madsmtm

Description

@madsmtm

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 on Code and Key
  • 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 for Modifiers
  • 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 Align NamedKey and KeyCode more closely with the W3C specs winit#4018.
  • Key::Character(String) is harder to match 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 has Key::Dead(Option<char>) to allow specify the character which is inserted when pressing the dead-key twice
  • Key::Space is missing, though perhaps Key::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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions