pyfisch / keyboard-types Goto Github PK

There is a number of commits since the last release v0.6.2...main, mainly modernizing the code and CI to conform to best practices.

@waywardmonkeys Thank you for updating the repository. Do you want to make more changes before the next release?

@madsmtm In #19 you outline the needs of winit. What are the current plans for integrating this crate into winit and which changes should be in the next release?

There's no function to get a Key from a &str, right? Do you plan to add such a function?

It could probably easily be generated by using convert.py and linear search, falling back to Key::Character if none of the other keys matches.

To implement: https://w3c.github.io/uievents/#determine-keydown-keyup-keyCode

Chrome seems to additionally define:

• BrightnessDown
• BrightnessUp
• DisplayToggleIntExt
• KeyboardLayoutSelect
• LaunchAssistant
• LaunchControlPanel
• LaunchScreenSaver
• MailForward
• MailReply
• MailSend
• MediaFastForward
• MediaPause
• MediaPlay
• MediaRecord
• MediaRewind
• PrivacyScreenToggle
• SelectTask
• ShowAllWindows
• ZoomToggle

First, a heads-up, we're in the process of adopting this crate as our standard keyboard event type in druid, see linebender/druid#1049 in particular. We appreciate having the crate are hopeful that it's a small step towards convergence in low-level platform integration the ecosystem.

There are a number of things we've run into as part of the integration. One ergonomics regression is that .shift (the old KeyModifiers was a struct of pub bools) has become .contains(Modifiers::SHIFT). Would you be open to an additional impl block with shift() and friends?

As a much lower priority, we also have an IntoKey trait that will convert any string into Key::Character(...), and this is used primarily to construct hotkeys. This has different semantics than your FromStr because it's not designed to parse strings like "Enter". It would be slightly more convenient for us to upgrade this to an Into, but I completely understand if you wouldn't want that.

There may be other work that makes sense to upstream, and if you're interested I can create additional issues.

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?
• 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.

In 59ab770, @pyfisch has support for F13-F35 keys.

Any chance that could land as part of the current batch of changes for a new release?

While the code values spec only allows very specific names, in practice (even the latest versions of) browsers still use values that predate the spec, such as:

Old Meta Values

• OSLeft for MetaLeft (Chrome <52, all Firefox versions, all Safari GTK and WPE versions)
• OSRight for MetaRight (Chrome <52, all Firefox versions, all Safari GTK and WPE versions)

Firefox Tracking Issue

Old Volume Values

• VolumeDown for AudioVolumeDown (Chrome <52, all Firefox versions)
• VolumeMute for AudioVolumeMute (Chrome <52, all Firefox versions)
• VolumeUp for AudioVolumeUp (Chrome <52, all Firefox versions)

Firefox Tracking Issue

Accidentally used key value for code (?)

• LaunchMediaPlayer for MediaSelect (all Safari GTK and WPE versions)

The spec explicitly mentions that those values are allowed and all the operating systems and browsers do in fact support them:

For keyboards that provide more than 12 function keys, the code value follows the pattern shown above with "F" followed by the function key number - "F13", "F14", "F15", and so on.

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.

Hi. I'm about to write a PS/2 keyboard driver for an embedded device (https://github.com/thejpster/monotron). Would you be interested in making this crate #![no_std] so I could use it in my project? Thanks!

PR #4 added FromStr trait for Key, however, there is no equivalent for Code. When used on the web, it feels natural to me to want to create a Code from an js_sys::KeyboardEvent::code(). Given that the two specification files are somewhat similar, it should not be too hard to add. Or do I miss something?

As you may know I'm in the progress of implementing the new winit keyboard input API here. I found another key variant which was missing, namely Finish. See: https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEvent/key/Key_Values

Opening an issue for this might be overkill but this seemed to be the most appropriate medium for communicating this.

In eea4b50, enum Code was accidentally not marked #[non_exhaustive]