Refactor use of ListView

[farao]

Attention: Currently not again in a working state. I tried to get this to run but currently it does not.

Two major changes:

1. Use ListView only for Status containers (Timelines and Threads).
   Reason for this is mostly to not need to adapt all the other Widgets).
2. In order to use the performance benefit of ListView: differente for
   Status between the setup of the widget and the (re)initialisation of
   the widget with content.

Point 2 could performancewise be (probably significantly) improved by moving more of the initialisation that's not content specific out of init() and into the empty Status constructor.

[farao]

@GeopJr The CI failure does not really seem to be caused by my change. But anyways this is a nonworking state, so it does not need to go through CI at the moment.

[GeopJr]

It was fixed on main, just pulled.

On #1301 I have a GTK patch that lowers the recycler's threshold. As it stands, ListView will only start recycling when it hits 200 items, so it's a bit hard to test for Tuba and to target down performance issues. edit: the 200 item threshold is hard coded, the only way to lower it is by compiling GTK. I wanted to make my own recycler for that and other reasons but ListView uses way too many private classes and widgets

One other thing I noticed on #1301, while most accessibility issues I had have been fixed, the scrolled position will jump around due to what I'm assuming is binding and different heights. So say there's a big post, 5k words, right at the start of the recycling view, you scroll a bit, the first post gets unbound so the whole view's height changes dramatically, causing the recycler to load it again since it scrolled up a bit and ends in a loop of binding and unbinding :////

edit: also please keep it as a draft, else I might accidentally merge it

[farao]

Ah, good thanks! I'll try it out in the following days :)

The bug with the chaotic jumps is unfortunately an underlying GTK bug. Fractal has it too (and is therefore near unusable on mobile). This is the gitlab issue: https://gitlab.gnome.org/GNOME/gtk/-/issues/6344. There is some initial investigation in the ticket but unfortunately no progress over many months (even though apparently all applications that use ListView or GridView are affected) :-/

[farao]

Have you tried out the state in this PR? It still (also with your added commits) doesn't load the timeline for me...

[GeopJr]

Sorry I havent had the time to take a deep look yet. The main problem is on_create_model_widget (i.item);

4 signals, the two we care about are setup and bind. setup gets called for generating blank widgets which we later bind on bind.

The thing is that we don't have access to the model item on setup, only on bind. So it's null on setup.

---

Think of it like this, a listview of labels and a model with random names. On setup you just create labels new Gtk.Label (""). On bind you bind the names child.label = item.

The listview generates a bunch of empty widgets (setup) and then recycles them as you scroll (bind).

---

The only way I can see this working without building the widget on bind is by having the contentbase know in advance what widgets it's going to build and do so in setup, but that won't work when there are different types of widgets.