[RFC] ListBox performance alternative

[GeopJr]

(I currently am dealing with COVID and my thoughts might be a bit incoherent)

I'm working on another app and since it's in early stages I am able to write widgets and views around ListView easily. The clear showstopper is accessibility. Unless I'm missing something, keyboard navigation can only navigate until the first child and then continues with the next row. (These have been mentioned before on the countless attempts at porting Tuba to ListViews).

So what if we just remove widgets at the top of the list when we reach a certain amount and re-add then when the user makes it to the top? Ex. The list has 40 posts, the user scrolls near the bottom, we remove 20 from the top, the user scrolls near the top, we add 10-20 back

This won't benefit from all the performance advantages of ListView (like re-using widgets) but it will reduce ram usage and general slowness significantly as both images and widgets will be destroyed.

One concern is keeping the scrollbar / view at the same position during the list changes

[nekohayo]

I'm a bit confused by the existence of this ticket versus the older (and much longer) issue #500, which mentions:

During the cleanup PR #424, we replaced the ListBox with ListView.

Is this here still relevant, and really different from #500?

[GeopJr]

#500 and the linked PRs are about ListView. The ListView migration was reverted shortly after due to the issues listed in #500

What has changed since is that the accessibility issues have been fixed from GTK's side but there are other issues with how the recycler works and scrolling so it has been put on pause yet again #1301 #1314.

---

This is an RFC about ListBox / the current views. On whether it's relevant... maybe? Our issues with ListView are nowhere near done so this existing as an alternative idea isn't that bad.