[PR #968] [CLOSED] Proof of concept: add support for opt-in inside-out keyboard event propagation #1085

New issue

Closed

opened 2026-03-04 01:09:22 +03:00 by kerem · 0 comments

kerem commented

2026-03-04 01:09:22 +03:00

Owner

📋 Pull Request Information

Original PR: https://github.com/rivo/tview/pull/968
Author: @GiGurra
Created: 4/19/2024
Status: ❌ Closed

Base: master ← Head: support-post-capture

📝 Commits (1)

5ec9818 add support for installing capture functions after general key processing, allowing for opt-in inside out even propagation

📊 Changes

19 files changed (+128 additions, -54 deletions)

View changed files

📝 application.go (+1 -1)
📝 box.go (+58 -12)
📝 button.go (+4 -2)
📝 checkbox.go (+4 -2)
📝 demos/primitive/main.go (+4 -2)
📝 dropdown.go (+4 -2)
📝 flex.go (+4 -3)
📝 form.go (+6 -4)
📝 frame.go (+4 -3)
📝 grid.go (+5 -3)
📝 inputfield.go (+5 -3)
📝 list.go (+4 -2)
📝 modal.go (+4 -3)
📝 pages.go (+4 -3)
📝 primitive.go (+1 -1)
📝 table.go (+4 -2)
📝 textarea.go (+4 -2)
📝 textview.go (+4 -2)
📝 treeview.go (+4 -2)

📄 Description

At present, it is not possible to (unless resorting to very unorthodox hacks) create inside-out event handler chains for keyboard events. This is useful in many applications (I ran into this with my first tview application), and is the default in the web world.

This PR is intended as a proof-of-concept rather than something to merge in its current form. Maybe there are better ways of solving this?

This PR creates an option where a user can opt-in to create inside out keyboard event propagation, by adding an additional captureFunctionAfter. The default such function just captures all events (to preserve tview's current semantics), but you can override this to add your own logic, filter out some for passing back to parents etc.

In order for this to be possible, a bool return value of the InputHandler() and WrapInputHandler functions indicating event consumption was added.

Existing widget/primitive specific input handlers have not been given any event consumption semantics, as that would change tview's semantic overall, plus different applications may wish to customize this, so consuming inside the default input handlers would (I suspect) break tons of applications.

This PR is perhaps more of a proof of concept than a finished solution - I'd just like to get the discussion going (and hopefully, if this PR or a variant of it, in the future gets merged I can remove my incredibly ugly hacks to emulate this i my own apps :))

Perhaps there are better ways of doing this? The base idea is - I really think tview would be a lot easier in many situations if inside-out event propagation was possible - if that comes in this form of a PR like mine, or totally different impl doesn't matter that much to me

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/rivo/tview/pull/968 **Author:** [@GiGurra](https://github.com/GiGurra) **Created:** 4/19/2024 **Status:** ❌ Closed **Base:** `master` ← **Head:** `support-post-capture` --- ### 📝 Commits (1) - [`5ec9818`](https://github.com/rivo/tview/commit/5ec9818914b033e6f5e17d413b9414cdc3529257) add support for installing capture functions after general key processing, allowing for opt-in inside out even propagation ### 📊 Changes **19 files changed** (+128 additions, -54 deletions) <details> <summary>View changed files</summary> 📝 `application.go` (+1 -1) 📝 `box.go` (+58 -12) 📝 `button.go` (+4 -2) 📝 `checkbox.go` (+4 -2) 📝 `demos/primitive/main.go` (+4 -2) 📝 `dropdown.go` (+4 -2) 📝 `flex.go` (+4 -3) 📝 `form.go` (+6 -4) 📝 `frame.go` (+4 -3) 📝 `grid.go` (+5 -3) 📝 `inputfield.go` (+5 -3) 📝 `list.go` (+4 -2) 📝 `modal.go` (+4 -3) 📝 `pages.go` (+4 -3) 📝 `primitive.go` (+1 -1) 📝 `table.go` (+4 -2) 📝 `textarea.go` (+4 -2) 📝 `textview.go` (+4 -2) 📝 `treeview.go` (+4 -2) </details> ### 📄 Description At present, it is not possible to (unless resorting to very unorthodox hacks) create inside-out event handler chains for keyboard events. This is useful in many applications (I ran into this with my first tview application), and is the default in the web world. ### **This PR is intended as a proof-of-concept rather than something to merge in its current form. Maybe there are better ways of solving this?** This PR creates an option where a user can opt-in to create inside out keyboard event propagation, by adding an additional captureFunctionAfter. The default such function just captures all events (to preserve tview's current semantics), but you can override this to add your own logic, filter out some for passing back to parents etc. In order for this to be possible, a bool return value of the InputHandler() and WrapInputHandler functions indicating event consumption was added. Existing widget/primitive specific input handlers have not been given any event consumption semantics, as that would change tview's semantic overall, plus different applications may wish to customize this, so consuming inside the default input handlers would (I suspect) break tons of applications. This PR is perhaps more of a proof of concept than a finished solution - I'd just like to get the discussion going (and hopefully, if this PR or a variant of it, in the future gets merged I can remove my incredibly ugly hacks to emulate this i my own apps :)) Perhaps there are better ways of doing this? The base idea is - I really think tview would be a lot easier in many situations if inside-out event propagation was possible - if that comes in this form of a PR like mine, or totally different impl doesn't matter that much to me --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>