Merged
Conversation
4 tasks
|
Looking forward to seeing this merged! Currently Blitz is using some custom code to convert between Winit events and keyboard_type events. I expect to do the same thing in Masonry. |
9 tasks
53dce06 to
d2c4d1b
Compare
madsmtm
commented
Mar 23, 2025
848ffc1 to
02d3456
Compare
kchibisov
approved these changes
Mar 23, 2025
Member
kchibisov
left a comment
There was a problem hiding this comment.
I think the concern with certain keys being deprecated is resolved? e.g. Copy key.
If it's true, then it's probably fine.
Member
Author
Yup, I didn't deprecate those in rust-windowing/keyboard-types#49. |
02d3456 to
7651fe8
Compare
Member
Author
|
I've released v0.8.0 of |
7651fe8 to
5011462
Compare
5011462 to
410fc7a
Compare
410fc7a to
c7b2eb9
Compare
|
\o/ |
mrobinson
added a commit
to mrobinson/servo
that referenced
this pull request
Dec 16, 2025
When no egui widget is focused, the `WebView` itself is effectively focused, so we should not forward keyboard events to egui. This change does that as well as switch the key processing function in `Gui` to use an early return approach for all events that should go immediately to the `WebView` or are otherwise consumed. Eventually, key events that are not consumed by the `WebView` should be forwarded back to `egui`, so that the user can, for instance, tab out of the `WebView`, but this requires having a version of winit with: rust-windowing/winit#4026 Signed-off-by: Martin Robinson <mrobinson@igalia.com>
github-merge-queue bot
pushed a commit
to servo/servo
that referenced
this pull request
Dec 16, 2025
…ed (#41314) When no egui widget is focused, the `WebView` itself is effectively focused, so we should not forward keyboard events to egui. This change does that as well as switch the key processing function in `Gui` to use an early return approach for all events that should go immediately to the `WebView` or are otherwise consumed. Eventually, key events that are not consumed by the `WebView` should be forwarded back to `egui`, so that the user can, for instance, tab out of the `WebView`, but this requires having a version of winit with: rust-windowing/winit#4026 Testing: This level of servoshell is untested unfortunately so no tests are added. Fixes: #41307. Signed-off-by: Martin Robinson <mrobinson@igalia.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Use and re-export
keyboard_types::NamedKey,keyboard_types::Codeandkeyboard_types::Locationfrom thekeyboard-typescrate.Unsure what the best way to re-export these is, we might for example want
#[doc(inline)]?I haven't used
keyboard_types::Modifiersyet, since that has a differentserdeimplementation, which is kind of an ABI break and might be hard for downstream to handle, see #4018 (comment). Also, it's not really compatible for other reasons, see #2394 (comment).Part of #2394. See also rust-windowing/keyboard-types#60.