Skip to content
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

Merged
merged 9 commits into from
Jan 11, 2021
Merged

keyboard global support #1271

merged 9 commits into from
Jan 11, 2021

Conversation

tehn
Copy link
Member

@tehn tehn commented Dec 15, 2020

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)

function keyboard.code(code,value) print(code,value) end
function keyboard.char(character) print(character) end
  • keyboard.code outputs HID code (converted to string for readability) and value
  • keyboard.char attempts to decode expected text (ie, reading shift) from a keymap

some util functions also (not to be redefined, just called directly):

  • keyboard.shift() returns true/false
  • same for alt, 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?

Copy link
Collaborator

@catfact catfact left a 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.

lua/core/keyboard.lua Show resolved Hide resolved
lua/core/keyboard.lua Outdated Show resolved Hide resolved
@tehn
Copy link
Member Author

tehn commented Dec 16, 2020

optimized, tested, works

bonus:

keyboard.state['A']

the reason i kept keyboard.shift() etc was a helper since there are two shifts (is that dumb?)

@catfact
Copy link
Collaborator

catfact commented Dec 16, 2020

oh, regarding non-ascii keys (like arrows, fns) it seems reasonable to me to only pass those in the code() callback.

@catfact
Copy link
Collaborator

catfact commented Dec 16, 2020

and oh, re: CR/enter

first, maybe it shouldn't be called ascii. that sort of implies some connection to actual ASCII encoding values (space = 32, etc), which AFAICT are unrelated.

maybe something like character, char, or string (to_string? yech) would be better - these objects are really strings of a single character that can be reasonably concatenated with other strings.

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)

@tehn
Copy link
Member Author

tehn commented Dec 16, 2020

agreed. s/ascii/char

to take a step back: is this even how the keymap should work with other keyboards?

ie, someone with a uk keyboard basically copies the us.lua file to uk.lua and changes $ to £ ? (trivializing, i'm sure there are more changes?)

@catfact
Copy link
Collaborator

catfact commented Dec 16, 2020

that seems reasonable, we could also scrape + generate these

@tehn
Copy link
Member Author

tehn commented Dec 28, 2020

ok. this basically works.

menu support is minimal:

  • up/down emulate enc2 (which is commonly scroll)
  • pageup/pagedown do enc2 with delta 6/-6
  • left/right do K2/K3
  • F1-F4 switch main modes (bug, makes E1 lose it's state)

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 _menu tables i think) to control screen/encs/keys. adding keyboard to this layer feels sloppy, so the current implementation doesn't serve these libs--- BUT this was one of the main requests for keyboard support--- typing in passwords and filenames.

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.

@tehn tehn merged commit b6a3181 into main Jan 11, 2021
@tehn tehn deleted the keyboard branch January 11, 2021 19:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants