Add native virtual keyboard typing for touch-first browsers - #364
Merged
Merged
Conversation
Translate committed native keyboard text into timed hardware key presses for C64, VIC-20, Oric, and Apple II. Show the keyboard input panel only in touch-first browsers, and yield browser frame processing to keep input and rendering responsive.
|
This branch was successfully deployed
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
1 participant
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.
Touch-first browser users can now open their device keyboard from the emulator sidebar and type into C64, VIC-20, Oric, or Apple II. Committed text becomes timed presses and releases at the emulated keyboard matrix or encoder, so input also reaches programs that read the hardware directly.
The Keyboard button is hidden in native desktop apps and mouse-first browsers, where physical and accessibility keyboards already use the existing input path. Browser availability follows the primary pointer capability and updates when it changes. Focus loss, Pause, Stop, and monitor opening cancel queued text; the browser bridge handles composition, paste, Return, and Backspace without duplicate input.
Browser frame processing also yields to the browser event loop after each frame, preventing an overrun loop from starving input and painting. A regression test reproduces the starvation before the fix.
Known limitation
The native keyboard is intended for typing. Each character is held for three emulator frames, followed by a two-frame release gap. It cannot reliably provide continuous holds or simultaneous controls for games, including WASD keyboard joystick movement. Dedicated touch controls and machine-specific Avalonia keyboard layouts remain separate future work.
Validation