Suppressing event for a bound key?

[SamStudio8]

Hi @willmcgugan, I've really enjoyed reverse engineering the examples and provided widgets to play with Textual and am loving the framework so far. I've been building a very small application out of curiosity and have a question about ignoring/suppressing key press events for bound keys when trying to accept user input to a focused widget.

My understanding so far is that Event objects are forwarded to a focused widget from its parent (in my case the App)? However it looks like the App gets first dibs on any events.Key events? This appears to have the side effect that my widget's on_key never sees messages for any bound keys as they've been consumed and the return will preclude the message getting sent around.

I might well have missed something here, so wonder what the recommended approach might be, otherwise it would be cool to have a chat in here on what a good solution might be. For my toy program, I've overloaded my App's on_event to check if the app's self.focused attribute is None before allowing the press to handle any potential bindings (of course I now have to ensure the "focus" is returned to None for the bindings to work, and also breaks Ctrl+C as it's just a regular binding too). Perhaps I should be temporarily removing the Bindings from the App while focus is on something else?

[willmcgugan]

Hi Sam,

Yeah, that is correct. The key event will get sent to the focused widget, but only if it is not bound.

I can see how there may be contexts where the widget should have the opportunity to process the key. Textual doesn't allow for that ATM so the question is probably how best change the API to add it.

Perhaps the key events should go to the widget first to give it a chance to process them. The event will propagate through the chain of parents to the App, which would then process the key bindings. But a widget could prevent that by calling event.stop(). Of course if nothing is focused the App would process the key as it does now.

Do you think that would cover your use case?

[SamStudio8]

It definitely would! I think it seems reasonable that the active widget gets first dibs on the input and the event bubbles up the tree to the App (if not stopped). Presumably this is a lot more API work than changing the App on_event but hopefully would offer more flexibility to Widgets. I wonder what this might mean for the Footer widget, how would it be able to know that events for its listed bindings might not reach it given the current Widget under focus (or the Widgets between the focus and the App)?

…

On Tue, 17 Aug 2021, 19:42 Will McGugan, ***@***.***> wrote: Hi Sam, Yeah, that is correct. The key event will get sent to the focused widget, but only if it is not bound. I can see how there may be contexts where the widget should have the opportunity to process the key. Textual doesn't allow for that ATM so the question is probably how best change the API to add it. Perhaps the key events *should* go to the widget first to give it a chance to process them. The event will propagate through the chain of parents to the App, which would then process the key bindings. But a widget could prevent that by calling event.stop(). Of course if nothing is focused the App would process the key as it does now. Do you think that would cover your use case? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#64 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAIN6OXUR7EYDDB4PS3C373T5KUP3ANCNFSM5CKLNI6Q> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email> .

[lllama]

Would Textual be able to support modal widgets like a confirmation dialog? If so, then it seems that they would probably need to capture all inputs until dismissed. You definitely wouldn't want them bubbling up to the app.

[willmcgugan]

I was thinking of having a stack of bindings (see bindings.py) where different contexts can be pushed and popped. This would handle the modal dialog that @lllama pointed out, but not the focused widget stoping the event from propagating. My gut feeling is that if you have a footer you design the keys so that the keys displayed take precedence over text input, i.e. Function keys or Ctrl+KEY

Any of this can change so let me know if you have other ideas!

[SamStudio8]

Perfect, pushing new sets of bindings to a stack for the current input/modal widget to handle first would work. I think you're right that setting up the footer to work under desired conditions is more of a usage problem than an API one. Although I wonder what should happen to Ctrl+C if you push a new set of bindings for say a modal dialogue. I guess the event could bubble up the binding stack?

…

On Wed, 18 Aug 2021, 08:23 Will McGugan, ***@***.***> wrote: I was thinking of having a stack of bindings (see bindings.py) where different contexts can be pushed and popped. This would handle the modal dialog that @lllama <https://github.com/lllama> pointed out, but not the focused widget stoping the event from propagating. My gut feeling is that if you have a footer you design the keys so that the keys displayed take precedence over text input, i.e. Function keys or Ctrl+KEY Any of this can change so let me know if you have other ideas! — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#64 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAIN6OT7E45EWQD5U2DHD4LT5NNYJANCNFSM5CKLNI6Q> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email> .

[wmshort]

Could it be feasible to assign a binding itself a kind of scope (widget, region, app), and thus supercedable (or not) by bindings in different contexts? Footer bindings, if desired, could be given global app scope but one can imagine specific widget contexts, like the modal dialogues, where you might want to temporarily override these.

[SamStudio8]

@wmshort My impression is that Will's plan for the stack of bindings would achieve this