-
Notifications
You must be signed in to change notification settings - Fork 147
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
keyboard global support #1271
keyboard global support #1271
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
overall looks like it will do the job.
i have only a few quite minor comments about code repetition etc.
optimized, tested, works bonus:
the reason i kept keyboard.shift() etc was a helper since there are two shifts (is that dumb?) |
oh, regarding non-ascii keys (like arrows, fns) it seems reasonable to me to only pass those in the |
and oh, re: CR/enter first, maybe it shouldn't be called maybe something like so to finally get to the point - it seems like you would only want enter = CR in a specific multi-line mode. maybe this is something to leave to the API consumer (text editor, command entry whatever) |
agreed. s/ascii/char to take a step back: is this even how the keymap should work with other keyboards? ie, someone with a |
that seems reasonable, we could also scrape + generate these |
ok. this basically works. menu support is minimal:
more generally, this brings to the fore that we're treading further into UI territory and focus management is really haphazard in the menu lua code (which is my fault, given i've been introducing features without a larger refactor). if someone is interested and ambitious about taking on the menu/focus mission it'd be welcomed. main crux: we have some libs (textentry, listselect, fileselect) that manage state (with some fragility using the partial/sloppy solution: in menu mode right now it's only looking at keycodes. i could reserve the global keychar function for lib use (primarily, textentry) also, right now each submenu can define its own custom keycode actions--- i started off by having each menu do everything, but a ton of redundancy reminded me that i should just have a global process first. of course, this doesn't quite fully apply, since the MIX and TAPE pages are particularly weird... but this is a good start. comments and design suggestions welcome. |
this is a proposal, needs feedback
keyboard
is now a global table. it responds to any HID keyboard connected (thanks @catfact for detection)user script callbacks (test cases shown below)
keyboard.code
outputs HID code (converted to string for readability) and valuekeyboard.char
attempts to decode expected text (ie, reading shift) from a keymapsome util functions also (not to be redefined, just called directly):
keyboard.shift()
returns true/falsealt
,ctrl
,meta
there's also a global state table(returns true/false per code):
keyboard.state['A']
keyboard.state.UP
my main question, given i am not an expert on keymaps and the linux keymap system looks like massive overkill-- what else is needed? is the approach i've taken insufficient?