Customn keyboard navigation

[bruno-rino]

I have a small app and I would like to assign extra meaning to the ENTER and ESC keys.
The TextInput widget has on_confirm that handles the ENTER key, I'll use that.
The Table widget has on_activate that handles double-click. I think it should also handle the ENTER key.

But that's only half the problem. Generic sounding events that would handling the ESC key don't come to mind. For that, I would need some on_keypress event (available in all widgets that can accept focus) that would allow me to listen to all keystrokes.

What are your views on that?

[freakboy3742]

At a high level - sure - I agree that there is scope to handle keyboard events in more situations. Podium (BeeWare's slide presentation app) is one example - it has custom keyboard handling specifically because of the limitations in Toga's default keyboard event handling.

The specific example of using ENTER as an alternative to on_activate on Table makes sense to me; but that doesn't require anything generic for keyboard handling - it's another event that we need to capture.

Beyond that, I guess the question is what that any other keyboard handling would actually look like - what use cases we're trying to handle, and where the right place to hook into that would be. Adding on_keypress on any focus-accepting widget makes at least some sense conceptually - although there's obviously overlap with any pre-existing or default keyboard handling to consider.

There's also "top level" keyboard handling - if I have a window that only has a box (or other static widgets), there's no focus, but obviously there's still a need to catch keyboard events.

[bruno-rino]

Hi! Thanks for the reply.

I took a quick look at Podium. I saw two keyboard handling methods at play:

• toga Commands, defined in app.py
• SlideDeck.on_key_press() method, defined in deck.py

I presume the second one is the custom handling you're referring to. But it doesn't seem to be called from anywhere. It seems to be just dead code now.

[freakboy3742]

The second is (broadly) what I was referring to; but it has been reworked in beeware/podium#65 because of differences in how keyboard events propagate on various web canvases.