IssueTracker

It also convenient to have active keyboard modifiers, for example, I need it in this CL

One approach is to add this information to PointerInputEvent (https://android-review.googlesource.com/c/platform/frameworks/support/+/1578803/12/compose/foundation/foundation/src/androidMain/kotlin/androidx/compose/foundation/text/selection/TextFieldSelectionManager.android.kt#21)

But I think there are cases when we need to know not only about keyboard modifiers. For example, if "W" was pressed when we focus (or open) the window:

• we open a simple game in which "W" means "go forward"
• we press "W"
• we minimize the window and pause the game
• we release "W" (or not)
• we restore the window
• at this moment we need to continue to move if "W" is still pressed, or stop moving

So we need an API for the current state of keyboard/mouse.

For example: LocalKeyboard.current.isKeyPressed(Key.W)

(can it be observable 🤔?)

But with this API we assume that there is only one keyboard. But we can connect and use two keyboards...

So we need an API for the current state of keyboard/mouse.

Actually, for your case, you only need to listen for KEY_PRESSED events

I afraid, that implementing such an interface could be tricky at the application level. A window can lose focus and an app stops receiving keyboard events. So it can get KEY_PRESSED but not KEY_RELEASED.

Thanks folks! Those are really good ideas.

I agree in general that even though the keys functionality is close with pointer input in certain important usecases, binding them together appears wrong to me and not flexible enough.

As for mouse clicks, I think it's possible to introduce it in the pointer event system and it makes a lot of sence of the first glance.

For example: LocalKeyboard.current.isKeyPressed(Key.W)

The idea is observable queries for keys sounds appealing to me, but I didn't spent much time thinking about it.

Let me cc Alex and Ralston who I think should see this. It seems like this bug is essentially two feature requests, so let's split them

Thanks for adding me to this discussion.

I'll try to explain what happens on Android. When a user persses a key on the keyboard, they will get a "KeyDown" event, and when they release the key they will get a "KeyUp" event. If the user keeps pressing the key, they will get multiple "KeyDown" events (eg typing "eeeeeeeeeeee" by just holding down the "e" key). When they finally release the key, they will get a single "KeyUp" event.

For the game, when the user minimises the screen, or clicks away from that window, the window loses focus, so it will not receive any more KeyEvents. At this point the game should be paused, and the current velocity saved. When the window gains focus again, the game is resumed and the application assumes that the "W" key was released, so the car starts slowing down. If however the W key was still pressed, the application will receive new "KeyDown" events and it can continue accelerating the car.

I want to avoid adding an API that allows the developer to check for the current state of the keyboard. I think only the component in focus should have access to the keyboard state. This gives the end-user control over where keyboard input is sent, and prevents other applications on the screen from listening/querying for keyboard state.