[GH-ISSUE #1104] [Feature Request] ScrollView Widget/Primitive

kerem commented

2026-03-04 01:07:51 +03:00

Owner

Originally created by @ossenthusiast on GitHub (Jul 20, 2025).
Original GitHub issue: https://github.com/rivo/tview/issues/1104

Add a new tview.Primitive that is a scrollable list of tview.Primitives.

Originally created by @ossenthusiast on GitHub (Jul 20, 2025). Original GitHub issue: https://github.com/rivo/tview/issues/1104 Add a new `tview.Primitive` that is a scrollable list of `tview.Primitive`s.

kerem commented

2026-03-04 01:07:52 +03:00

Author

Owner

@ossenthusiast commented on GitHub (Jul 21, 2025):

Do you still maintain this? @rivo

@ossenthusiast commented on GitHub (Jul 21, 2025): Do you still maintain this? @rivo

kerem commented

2026-03-04 01:07:52 +03:00

Author

Owner

@rivo commented on GitHub (Jul 21, 2025):

Yes. Please be patient.

@rivo commented on GitHub (Jul 21, 2025): Yes. Please be patient.

kerem commented

2026-03-04 01:07:52 +03:00

Author

Owner

@rivo commented on GitHub (Jul 21, 2025):

Also, I'm not sure what you mean by "scrollable list of Primitives". You might want to elaborate. With examples, if possible.

@rivo commented on GitHub (Jul 21, 2025): Also, I'm not sure what you mean by "scrollable list of `Primitive`s". You might want to elaborate. With examples, if possible.

kerem commented

2026-03-04 01:07:52 +03:00

Author

Owner

@ossenthusiast commented on GitHub (Jul 21, 2025):

Also, I'm not sure what you mean by "scrollable list of Primitives". You might want to elaborate. With examples, if possible.

Sorry for the mention. I mean basically a scrollable horizontal layout (list) of widgets.

tview.NewScrollList().
    Append(tview.NewInputField()).
    Append(tview.NewBox()).
    Append(tview.NewFlex())

@ossenthusiast commented on GitHub (Jul 21, 2025): > Also, I'm not sure what you mean by "scrollable list of `Primitive`s". You might want to elaborate. With examples, if possible. Sorry for the mention. I mean basically a scrollable horizontal layout (list) of widgets. ```go tview.NewScrollList(). Append(tview.NewInputField()). Append(tview.NewBox()). Append(tview.NewFlex()) ```

kerem commented

2026-03-04 01:07:52 +03:00

Author

Owner

@rivo commented on GitHub (Aug 27, 2025):

Flex is basically that. But it's not scrollable. The question with these suggestions is: How would you control the scrolling? Let's say one of the contained elements is a TextArea and the user is currently entering text. Which keys would you assign to scrolling the Flex?

@rivo commented on GitHub (Aug 27, 2025): `Flex` is basically that. But it's not scrollable. The question with these suggestions is: How would you control the scrolling? Let's say one of the contained elements is a `TextArea` and the user is currently entering text. Which keys would you assign to scrolling the `Flex`?

kerem commented

2026-03-04 01:07:52 +03:00

Author

Owner

@ossenthusiast commented on GitHub (Aug 27, 2025):

Flex is basically that. But it's not scrollable. The question with these suggestions is: How would you control the scrolling? Let's say one of the contained elements is a TextArea and the user is currently entering text. Which keys would you assign to scrolling the Flex?

Thanks for the response! I am aware of Flex, but fundamentally, a flexbox is not meant to be scrollable. This is where ScrollView comes in. This is a very common requirement by a lot of TUI applications: you want to display a list of "messages" that the user can perform "actions" on (delete, edit, etc.). Regarding navigation, I would recommend following traditional vim-like keybindings for autocomplete menu:

Ctrl+P = Focus Previous
Ctrl+N = Focus Next

@ossenthusiast commented on GitHub (Aug 27, 2025): > `Flex` is basically that. But it's not scrollable. The question with these suggestions is: How would you control the scrolling? Let's say one of the contained elements is a `TextArea` and the user is currently entering text. Which keys would you assign to scrolling the `Flex`? Thanks for the response! I am aware of `Flex`, but fundamentally, a flexbox is not meant to be scrollable. This is where `ScrollView` comes in. This is a very common requirement by a lot of TUI applications: you want to display a list of "messages" that the user can perform "actions" on (delete, edit, etc.). Regarding navigation, I would recommend following traditional vim-like keybindings for autocomplete menu: Ctrl+P = Focus **P**revious Ctrl+N = Focus **N**ext

kerem commented

2026-03-04 01:07:52 +03:00

Author

Owner

@ossenthusiast commented on GitHub (Aug 28, 2025):

Alternatively, you could just expose two methods FocusPrevious and FocusNext, which the user can use to set an input capture callback themselves for navigation instead of handling defaults. Furthermore, if you don't like the above approach, you could also accept extra arguments in the constructor of ScrollView (NewScrollView) primitive: focusNextKey and focusPreviousKey, both are of type tcell.EventKey:

tview.NewScrollNew(tcell.NewEventKey(KeyUp, ...), tcell.NewEventKey(KeyDown, ...))

@ossenthusiast commented on GitHub (Aug 28, 2025): Alternatively, you could just expose two methods `FocusPrevious` and `FocusNext`, which the user can use to set an input capture callback themselves for navigation instead of handling defaults. Furthermore, if you don't like the above approach, you could also accept extra arguments in the constructor of `ScrollView` (`NewScrollView`) primitive: focusNextKey and focusPreviousKey, both are of type `tcell.EventKey`: ```go tview.NewScrollNew(tcell.NewEventKey(KeyUp, ...), tcell.NewEventKey(KeyDown, ...)) ```

kerem commented

2026-03-04 01:07:52 +03:00

Author

Owner

@rivo commented on GitHub (Aug 28, 2025):

Actually, the main problem is not so much the navigation itself — I'd argue that you can do this today by removing/adding items from a Flex as needed, resulting in a scroll-by-flex-row effect — but that, as mentioned many times in other issues, primitives don't propagate their optimal size upwards. In a chat application, there are some longer messages and some shorter ones. It is currently not possible to size a Flex's child primitive so it fits its contents optimally and there are no plans to introduce this. (This is quite a difficult problem to solve anyway.)

The question for such apps is also, why would you need to add any primitive to such a layout? Flex or Grid are primarily aimed at placing interactive controls on the screen, like input fields, checkboxes, buttons, text areas, etc. It strikes me that a chat application is mostly about formatting a long list of text messages, rather than placing interactive controls on screen. Instead of placing dozens or hundreds of small TextView elements into a Flex, it may make more sense to put them all into one TextView, a primitive which is specifically made to display large amounts of text (and it's scrollable, too). It's also flexible in terms of text size: If there is more text, it will expand to more lines automatically.

I get that at this point, formatting messages in a TextView for a chat/messages app may be difficult. But I would think that this is a problem that can be solved a lot more easily than inventing a new container primitive. (I seem to recall an issue asking for something like this but I cannot find it right now.)

@rivo commented on GitHub (Aug 28, 2025): Actually, the main problem is not so much the navigation itself — I'd argue that you can do this today by removing/adding items from a `Flex` as needed, resulting in a scroll-by-flex-row effect — but that, as mentioned many times in other issues, primitives don't propagate their optimal size upwards. In a chat application, there are some longer messages and some shorter ones. It is currently not possible to size a `Flex`'s child primitive so it fits its contents optimally and there are no plans to introduce this. (This is quite a difficult problem to solve anyway.) The question for such apps is also, why would you need to add *any* primitive to such a layout? `Flex` or `Grid` are primarily aimed at placing interactive controls on the screen, like input fields, checkboxes, buttons, text areas, etc. It strikes me that a chat application is mostly about formatting a long list of text messages, rather than placing interactive controls on screen. Instead of placing dozens or hundreds of small `TextView` elements into a `Flex`, it may make more sense to put them all into one `TextView`, a primitive which is specifically made to display large amounts of text (and it's scrollable, too). It's also flexible in terms of text size: If there is more text, it will expand to more lines automatically. I get that at this point, formatting messages in a `TextView` for a chat/messages app may be difficult. But I would think that this is a problem that can be solved a lot more easily than inventing a new container primitive. (I seem to recall an issue asking for something like this but I cannot find it right now.)

kerem commented

2026-03-04 01:07:52 +03:00

Author

Owner

@rivo commented on GitHub (Sep 4, 2025):

FYI, I added a very simple chat application which illustrates how you might deal with flexible paragraphs:

https://github.com/rivo/tview/tree/master/demos/textview/chat

@rivo commented on GitHub (Sep 4, 2025): FYI, I added a very simple chat application which illustrates how you might deal with flexible paragraphs: https://github.com/rivo/tview/tree/master/demos/textview/chat

kerem commented

2026-03-04 01:07:52 +03:00

Author

Owner

@ossenthusiast commented on GitHub (Sep 4, 2025):

FYI, I added a very simple chat application which illustrates how you might deal with flexible paragraphs:

https://github.com/rivo/tview/tree/master/demos/textview/chat

Thanks! A common thing chat apps have is being able to select a "message" and perform certain actions on it (delete, edit, etc, navigate using keys, etc), how would you implement that while being performant? For example, I have used region IDs and highlights to mimic that behavior in my chat TUI for Matrix, but to update a single message, I would have to remove the message and then redraw everything to TextView, which is pretty slow. This has been a pretty major pain-point for me with tview. Looking forward to your thoughts on this!

@ossenthusiast commented on GitHub (Sep 4, 2025): > FYI, I added a very simple chat application which illustrates how you might deal with flexible paragraphs: > > https://github.com/rivo/tview/tree/master/demos/textview/chat Thanks! A common thing chat apps have is being able to select a "message" and perform certain actions on it (delete, edit, etc, navigate using keys, etc), how would you implement that while being performant? For example, I have used region IDs and highlights to mimic that behavior in my chat TUI for Matrix, but to update a single message, I would have to remove the message and then redraw everything to TextView, which is pretty slow. This has been a pretty major pain-point for me with tview. Looking forward to your thoughts on this!

kerem commented

2026-03-04 01:07:52 +03:00

Author

Owner

@ossenthusiast commented on GitHub (Sep 4, 2025):

BTW, the chat demo uses the (*tview.TextView).GetRegions function, which does not exist.

@ossenthusiast commented on GitHub (Sep 4, 2025): BTW, the chat demo uses the `(*tview.TextView).GetRegions` function, which does not exist.

kerem commented

2026-03-04 01:07:53 +03:00

Author

Owner

@rivo commented on GitHub (Sep 4, 2025):

BTW, the chat demo uses the (*tview.TextView).GetRegions function, which does not exist.

It does for me: github.com/rivo/tview@4cdaaa9bd6/textview.go (L823)

@rivo commented on GitHub (Sep 4, 2025): > BTW, the chat demo uses the `(*tview.TextView).GetRegions` function, which does not exist. It does for me: https://github.com/rivo/tview/blob/4cdaaa9bd6f6dcf226f43644d00f6b5703d69a8b/textview.go#L823

kerem referenced this issue

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

[PR #802] Grid items can be cleared after the given index #1045

Rows
Columns

[GH-ISSUE #1104] [Feature Request] ScrollView Widget/Primitive #802