Horizontal scrolling of the built-in List component

[kxxt]

Hi 👋 ,

I am using ratatui to build my tracexec program. One problem I encountered is that the built-in List component doesn't support horizontal scrolling. I am not sure if there's a well documented/tested approach to implement this feature or I have to create a custom List component or there is already a custom list component having this feature?

Thanks for creating and maintaining this amazing TUI library!

Edit: Oh, I opened this discussion at a wrong repo accidentally.

[joshka]

(I moved this over to the ratatui repo from the website repo)

There's nothing built-in to the list for this scenario. Depending on how you want this to work, I'd suggest the following approaches:

• If you're trying to scroll a single line within the list leaving the other lines alone, then you could implement this as a truncation of the item based on the scroll position and selected index. This assumes you're ok with building the list items every time the selection changes (for small lists this is not a measurable problem, for larger ones, it might be).
• If you're trying to scroll the entire list horizontally, take a look at tui-scrollview as a way to create an intermediate buffer that supports scrolling. (Note that horizontal scrolling isn't properly implemented yet, but it's probably a pretty simple fix)

[kxxt]

(Actually I just checked) - horizontal scrolling works, I just didn't implement a scrollbar for it yet - mainly because I wanted the conditional scrollbar visibility before adding in the horizontal bar, but that's no big deal.

I implemented both of them in joshka/tui-scrollview#30 but I haven't updated the tests so it's still a draft PR.

[kxxt]

@joshka I have added tests and updated the example. I think joshka/tui-scrollview#30 is now ready for review

[kxxt]

I evaluated joshka/tui-scrollview#30 (and also tried unstable feature StatefulWidgetRef) on my program. Unfortunately I can't use it because of performance reasons. My list items' width can easily exceed 7000 characters and I might even have to consider the case that the width overflow u16::MAX. So it's no really feasible to render them in a large buffer. I will try to render only the part of the line that are visible as I already implemented a lazy list to some extent. Even though I think only rendering part of a line might be challenging.

[joshka]

Definitely we want to make (performant) partial / scrolled rendering a bit more of the normal thing across all the widgets. There's a pretty large Issue #174 that talks about all sorts of parts of this.

Ideally, you would want to have a list that knows how to just render the visible part when scrolled horizontally avoiding having to render all the non-visible areas. Aside from just the inherent complexity of that, Unicode makes this more difficult, as characters can each have a different width.

Unblocking yourself in a performant way, I think I'd probably take the approach of pre-truncating the visible list items based on the horizontal scroll position kept externally.

You could also bake this into the rendering function of a widget that is a copy of the existing widget.

It's also possible that you could make this work by putting scrolled paragraphs in a tui-widget-list - I haven't used the crate personally however. It might be worth a try though.

[kxxt]

Definitely we want to make (performant) partial / scrolled rendering a bit more of the normal thing across all the widgets. There's a pretty large Issue #174 that talks about all sorts of parts of this.

Yes, implementing partial rendering is very complex in general. But in my use case it's relatively simple since I only need to deal with Lines and I already implemented it: https://github.com/kxxt/tracexec/blob/main/src/tui/partial_line.rs#L11-L80 and it nicely meets my performance requirements.

Ideally, you would want to have a list that knows how to just render the visible part when scrolled horizontally avoiding having to render all the non-visible areas. Aside from just the inherent complexity of that, Unicode makes this more difficult, as characters can each have a different width.

Thanks for reminding me of the Unicode complexity, which I am not aware of previously.