gtk: route pointer and key input to the Surface - #95
Merged
Conversation
The GTK back-end could open a window and host native controls, but its DRAWN regions — the whole self-rendering Surface outside the overlaid controls — were dead: no click, scroll or keystroke reached them, so on Linux the reader could not even be navigated to a view. Attach go-gtk v0.3.0's event controllers to the window and translate each into a toolkit.Event delivered to the root, then mark dirty so the frame clock presents the result — the same event shapes and DOM-style key names the Cocoa/X11 backends emit (EventClick/MouseUp/Move/Drag, EventSecondaryClick for the right button, EventScroll in ±1 rows with no inversion, EventKeyDown/Up/Char). The native controls still receive their own input from GTK and consume it first. Proven end to end: newsreader -window under Xvfb, a synthetic click on the Settings item navigates from the feed to the Settings view (its native text fields render). Display-free tests cover the key-name/scroll/modifier/button mapping; bumps go-gtk v0.2.4 → v0.3.0.
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.
The GTK backend could open a window and host native controls, but its drawn regions — the whole self-rendering Surface outside the overlaid controls — were dead: no click, scroll or keystroke reached them, so on Linux the reader couldn't even be navigated to a view. Attaches go-gtk v0.3.0's event controllers to the window and translates each into a
toolkit.Eventdelivered to the root, then marks dirty so the frame clock presents the result — the same event shapes and DOM-style key names Cocoa/X11 emit (Click/MouseUp/Move/Drag, SecondaryClick for the right button, Scroll in ±1 rows with no inversion, KeyDown/Up/Char). Native controls still receive their own input from GTK and consume it first.Proven end-to-end:
newsreader -windowunder Xvfb, a synthetic click on the Settings item navigates from the feed to the Settings view. Display-free tests cover the key-name/scroll/modifier/button mapping. Bumps go-gtk v0.2.4 → v0.3.0.