pyfisch / keyboard-types Goto Github PK
View Code? Open in Web Editor NEWTypes to define keyboard related events.
License: Apache License 2.0
Types to define keyboard related events.
License: Apache License 2.0
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.
Chrome seems to additionally define:
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:
F25-F35
variants on Code
and Key
Modifiers
at some point? (e.g. LALT
/RALT
, LCTRL
/RCTRL
, ...)winit
has a bit of a different serialization logic for Modifiers
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>
.
winit
has Key::Dead(Option<char>)
to allow specify the character which is inserted when pressing the dead-key twiceKey::Space
is missing, though perhaps Key::Character(" ")
is indeed cleanerA 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
.
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:
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)VolumeDown
for AudioVolumeDown
(Chrome <52, all Firefox versions)VolumeMute
for AudioVolumeMute
(Chrome <52, all Firefox versions)VolumeUp
for AudioVolumeUp
(Chrome <52, all Firefox versions)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]
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.