-
Notifications
You must be signed in to change notification settings - Fork 45
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
key events #35
Comments
Wait, if I do:
And type "Shift-K", I get an object with:
So some of these are certainly present. If I type Option-[ (for curly quote on a Mac), I get:
I think that the modifier keys are reasonably cross-browser (Caps Lock isn't considered a modifier key). I think getting option-based input via OSX is probably best done by hiding a text area and focusing that, then reading the input out of it after an "input" event, rather than rebuilding the modifier logic ourselves. (NB: This is all in Chromium, but CPO does Ctrl-S and Ctrl-Enter for save/run this way, and it works across all the major browsers). |
Huh? keypress isn't fired if you just hit a modifier key. |
Agreed. I didn't realize part of the goal was to fire key events for standalone modifier keys; I thought you were just saying it was hard to get the modifier information period. I take it you want to support a key event that fires "Shift" and having Shift+a show up as "A" for the key? Or is there another reason keydown rather than keypress is necessary? |
If we want to preserve compatibility with DrRacket's on-key handler, we need to use keydown. |
Small poke. Seems relevant in light of https://groups.google.com/forum/#!topic/pyret-discuss/lEDVirNisRI |
One of the teachers at the physics workshop had asked whether we had key-down vs. key-up events. |
Per the thread on pyret-discuss:
Regardless of the more detailed function, |
I'd suggest something like |
Concrete proposal:
Where
Feel free to point out missing things in the above definition. |
How does this interact with on-key handlers? Which happens first? Do we call both on-key and on-raw-key for sustained keypresses? Or do we make it a well-formedness error to have both kinds of key handlers? |
Proposal: It's a well-formedness error to have both. |
I like this. Can you say more about what |
We've discussed this a bunch this morning while resolving https://github.com/brownplt/code.pyret.org/pull/167/files It seems like the To answer the direct, most recent question, if a user typed "Alt-Shift Y" on OSX (which produces Á on my laptop), there would be three calls to the reactor's
Since students already (implicitly) learn to filter out keys in games to not crash Of course, we should also add |
It looks like PR #262 may have come almost all the way to implementing this. Is it stuck in PR purgatory, or did it get implemented elsewhere? |
@jpolitz I know you have a PR for this. I'm guessing it's gone stale? Could this be something for an undergrad to clean up? |
@jpolitz did this PR ever get merged? |
This comes as no surprise to anyone, but I've been knee-deep in it with WeScheme for the last few days so I figured I might as well file a report. This is based on the Pyret program found at https://code.pyret.org/editor#share=0BzzMl1BJlJDkeFFTUVhURk1rd0E&v=v0.5r1428
I don't know how much of the old jsBigBang code Pyret inherited, but here's the issue: the only way to get modifier keys (shift, alt, etc) is to listen for keydown events, and the only [easy] way to get the modified character (ç) is to listen for keypress events.
I briefly attempted to reconstruct the typed character solely from the keydown event, but that got complicated fast. For WeScheme, I instead signed up the key-event handler for both down and press, and then had it sift through some conditions to know when to ignore one and listen for the other. It feels like a bit of a fragile solution, but I don't expect anyone to re-assign the extended ASCII character set anytime soon. :)
Hope this is helpful!
The text was updated successfully, but these errors were encountered: