[GH-ISSUE #243] Shutdown event watching should be configurable. #189

New issue

Closed

opened 2026-03-04 01:02:46 +03:00 by kerem · 1 comment

kerem commented

2026-03-04 01:02:46 +03:00

Owner

Originally created by @IngCr3at1on on GitHub (Feb 25, 2019).
Original GitHub issue: https://github.com/rivo/tview/issues/243

Currently in application.go.Run the following code block exists:

				// Ctrl-C closes the application.
				if event.Key() == tcell.KeyCtrlC {
					a.Stop()
				}

while this is appropriate for most applications there are some cases where the consuming application will want to change this behavior.

Possible solution 1:
add a var to the application struct:
KeyInterceptorF func(app Application, key tcell.Key)

and provide a default value:

func defaultKeyInterceptorF(app Application, key tcell.Key) {
    if key == tcell.KeyCtrlC {
        app.Stop()
    }
}

The above is partly incomplete but should give an idea of what I'm suggesting.

Possible solution 2:
simply add an easy way to disable the current check and leave calling stop entirely up to the consumer in that situation.

I would be happy to implement either of these myself.

Originally created by @IngCr3at1on on GitHub (Feb 25, 2019). Original GitHub issue: https://github.com/rivo/tview/issues/243 Currently in application.go.Run the following code block exists: ``` // Ctrl-C closes the application. if event.Key() == tcell.KeyCtrlC { a.Stop() } ``` while this is appropriate for _most_ applications there are some cases where the consuming application will want to change this behavior. --- Possible solution 1: add a var to the application struct: `KeyInterceptorF func(app Application, key tcell.Key)` and provide a default value: ``` func defaultKeyInterceptorF(app Application, key tcell.Key) { if key == tcell.KeyCtrlC { app.Stop() } } ``` --- The above is partly incomplete but should give an idea of what I'm suggesting. --- Possible solution 2: simply add an easy way to disable the current check and leave calling stop entirely up to the consumer in that situation. --- I would be happy to implement either of these myself.

kerem closed this issue

2026-03-04 01:02:46 +03:00

kerem commented

2026-03-04 01:02:46 +03:00

Author

Owner

@IngCr3at1on commented on GitHub (Feb 28, 2019):

After some extra fiddling it appears the behavior I want can be handled using app.SetInputCapture.

Closing

@IngCr3at1on commented on GitHub (Feb 28, 2019): After some extra fiddling it appears the behavior I want can be handled using app.SetInputCapture. Closing