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

Expose function to read a key (any key)? #161

Closed
kgrossjo opened this issue Jan 8, 2017 · 3 comments
Closed

Expose function to read a key (any key)? #161

kgrossjo opened this issue Jan 8, 2017 · 3 comments
Labels

Comments

@kgrossjo
Copy link

kgrossjo commented Jan 8, 2017

  • Version: 2.4 (55)
  • macOS: 10.12.2 (Sierra)

If I want to read a string from the user, I have to enable handlers for all the keys the user might press when entering a string. (I would also have a handler for the esc key -- it would abort reading the string, and a handler for the return key -- it would terminate the string and confirm.)

But which keys the user might press? That depends on the keyboard layout. So actually reading a string from the user is not so easy.

WIBNI Phoenix allowed me to read a key (any key) from the user, then look at the key and decide what to do next?

@kasper
Copy link
Owner

kasper commented Jan 9, 2017

I feel this starts to go out of scope for this app.

  1. I could implement an event that would register all key presses, but those would not be exclusive. This would mean other apps might and would act on them as well. Not really useful.
  2. You can implement this yourself by binding to all available keys in your local keyboard layout. Sure, it’s not a global solution across keyboard layouts. (We could have a setting to fix the keyboard layout.)
  3. This starts to go outside of the intent of the app and I want to keep it clean.

A more suitable solution, which many are trying to mimic, would be to have a modal with an input. This way you could enter textual commands.

@kgrossjo
Copy link
Author

kgrossjo commented Jan 9, 2017

Oh yes! Oh yes! A modal with an input! Oh yes! That's what I wanted, but I didn't dare to ask!

@kasper kasper added the wontfix label Jan 22, 2017
@kasper
Copy link
Owner

kasper commented Jan 22, 2017

Closed for #163.

@kasper kasper closed this as completed Jan 22, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants