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

feature request - non-blocking / timeout #62

Open
2sn opened this issue Apr 3, 2021 · 4 comments · May be fixed by #96
Open

feature request - non-blocking / timeout #62

2sn opened this issue Apr 3, 2021 · 4 comments · May be fixed by #96

Comments

@2sn
Copy link

2sn commented Apr 3, 2021

Is there a way to have a non-blocking version that returns None or raises an exception if there no current key?

Or, even better, to have a timeout, and then do the above after the timeout has passed and no key was pressed or no character entered, respectively?

@2sn
Copy link
Author

2sn commented Jul 5, 2022

Excellent. Thanks a lot!

@Cube707
Copy link
Collaborator

Cube707 commented Jul 5, 2022

we will see when magmax comes back and merges it 😃

@Cube707
Copy link
Collaborator

Cube707 commented Jul 20, 2022

So, turns out stuff is more complex on the linux side... Which is why I removed this feature form the v4 development for now.

When working on linux systems, we need to reconfigure the terminal to fit readchars needs (don't echo pressed keys back to the user, don't stop on CTRL+C, etc.). This happens when readchar() is called and gets reset before the function finishes. This is fine when blocking untill a key is pressed but when spending a lot of time outside of readchar and little time inside it to actually check for keypresses, this leads to unexpected behavior in form of random echoed letters.

The easiest soloution is probably to use multiple threads and have readchar block one of them and wait for input, this way the thread could also be terminated if need be. (See here for example.)

To get this behavior working on a single thread the user would have to first set up the Terminal, then run his code and then runs some more code to reset the terminal. This would call for a context-manager and is defnetly possible, but making it libary read is difficult and it would add much more complexety when using the libary. Here is a example of how it could look:

with KeyReader() as r:
    spinner = cycle(["-", "/", "|", "\\"])
    while True:
        print("\rpress a key: " + next(spinner), end="")
        if r.kbhit():
            k = r.readkey()
            print(f"\r{k.encode()}-key was pressed")

        # do other stuff

would this be of use to you if it was part of the libary?

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 a pull request may close this issue.

2 participants