Open leostera opened 11 months ago
As an update, we now have a key
variant that we're mapping around the same place in the code, so when you match on a KeyDown
event you can discover quickly what the available keys are, and also have some guarantees that your app won't break.
Hey! I would love to contribute by adding support for modifier keys.
so far, the Key variation is only a string
type key =
| Up
| Down
| Left
| Right
| Space
| Escape
| Backspace
| Enter
| Key of string
which means its not straight forward to just add a modifier to the key pressed without breaking the interface unless I add a new variation. But I think its a bad API to have both Key
and other event for Key with modifier
.
I thought about making it be Key of key_event
in which key_event would be something like:
type key_modifier =
| Ctrl
| Alt
| Shift
type key_event = {
key : string;
modifier : key_modifier;
}
This would allow for telling which modifier was pressed with a key. But again, this would be a breaking change to the interface, which also requires to change all the examples.
What do you think?
As discussed in #45 we chose to use a pair of key * modifier
and make the modifier a variant that includes a No_modifier
constructor, so matching on a key event looks like:
| KeyDown (Key "j" | Left, No_mofidier | Shift) -> ...
At the moment we are only handling the space
" "
and keys in a nice way, but it'd be nice to be able to match onKeyDown Enter
orKeyDown "<enter>"
.Using a variant for all the keys may be a stretch, since we're parsing UTF-8 grapheme clusters, so at least some common ones we want to handle in a way that lets you match over KeyDown easily.
This is currently happening in the
minttea/io_loop.ml
in thetranslate
function:https://github.com/leostera/minttea/blob/main/minttea/io_loop.ml#L18
Currently implemented keys:
Missing keys: