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

Map more UTF-8 key events #3

Open
6 of 10 tasks
leostera opened this issue Dec 14, 2023 · 3 comments
Open
6 of 10 tasks

Map more UTF-8 key events #3

leostera opened this issue Dec 14, 2023 · 3 comments
Labels
enhancement New feature or request good first issue Good for newcomers help wanted Extra attention is needed

Comments

@leostera
Copy link
Owner

leostera commented Dec 14, 2023

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 on KeyDown Enter or KeyDown "<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 the translate function:

https://github.com/leostera/minttea/blob/main/minttea/io_loop.ml#L18


Currently implemented keys:

  • Enter
  • Space
  • Backspace
  • Left / Down / Up / Right
  • Escape
  • Key (includes a string with the contents of the matched UTF-8 character)

Missing keys:

  • Shift-modifier
  • Ctrl-modifier
  • Alt-modifier
  • ???
@leostera leostera added enhancement New feature or request good first issue Good for newcomers help wanted Extra attention is needed labels Dec 14, 2023
@leostera
Copy link
Owner Author

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.

@wllfaria
Copy link
Contributor

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?

@leostera
Copy link
Owner Author

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) -> ...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request good first issue Good for newcomers help wanted Extra attention is needed
Projects
Status: No status
Development

No branches or pull requests

2 participants