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

Handling Alt-Tab. #1046

Open
skejeton opened this issue May 13, 2024 · 4 comments
Open

Handling Alt-Tab. #1046

skejeton opened this issue May 13, 2024 · 4 comments
Assignees
Labels

Comments

@skejeton
Copy link
Contributor

skejeton commented May 13, 2024

So, Sokol receives the Alt key input when you press Alt, and when you press Tab, the window changes. Then Sokol doesn't receive the Alt key release. That means when I come back to the program, the Alt key will still be registered as pressed. There seems to be no work around for this. What should I do?

@skejeton
Copy link
Contributor Author

So, there's one solution is by detecting window unfocus to drop the key states.

@floooh
Copy link
Owner

floooh commented May 14, 2024

Hmm yeah, I haven't been sure tbh whether it should be the responsibility of the user code to drop key presses that were stuck when the window loses focus, or whether sokol_app.h should do this automatically.

I'll try to have a look how GLFW handles this. It probably makes sense to copy their behaviour. It may be tricky on more esoteric platforms like the web though.

In general, listening for the events like UNFOCUSED is the correct workaround.

@floooh floooh self-assigned this May 14, 2024
@floooh floooh added the bug label May 14, 2024
@floooh
Copy link
Owner

floooh commented May 14, 2024

...on further thought, it's tricky to handle inside sokol_app.h I would basically need to remember any pressed key, and then send a KEY_UP event on unfocused (and probably other events like minimized). Since sokol_app.h input is event-based (and not polling-based), that doesn't quite fit int since in an event-driven API there isn't a relationship between different types of input events.

I keep rolling around the idea in my head to have a input-polling header which sits on top of sokol_app.h and which would keep track of input events and offer a simple polling API (which makes a lot more sense for games), and this the unfocused-fix would make a lot more sense such a polling-layer.

@skejeton
Copy link
Contributor Author

skejeton commented May 14, 2024

The unfocus workaround worked super well for all my projects, so this can be the reasonable fix users will need to implement.

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