GTK: Infinite lazy list of widgets

Question

I need to display a virtually infinite scrollabe list of interactive widgets and add/remove them as necessary when new data is added or the user scrolls into an uncached area.

A TreeView (as asked about here) is no option, because, I need full Widgets as items (composed of standard widgets with multiple actions etc, but CellRenderer isn't for this)

Worse, I don't know my widgets' height in advance (not much variance though), so using a VBox might cause jumpiness.

Using the scrollbar should still feel as if the list was finite (i.e. updated only after scrolling has finished so the scrollbutton doesn't jump away from your mouse), and when resizing the window and the layout of the windows is updated, the scroll position shouldn't change too much (the focused widget should stay where it is, unless of course the focused widget was scrolled away…).

What's the best way to do this? Maybe even a library that just sends me signals when a new widget needs to be added?

Or could the ListView be coerced to do this in a not-too-nasty way? (i.e. draw on an offscreen buffer, copy that into the cell using CellRenderer, relay mouse/keyboard events to the actual widget?)

Theophrastus

What do you mean by "jumpiness"? What's the problem with VBox ? – Ebby

if the user scrolls upwards, the average widget height is 200px (i.e. I have a number of blank cells 200px high out of view which I replace with the actual widgets as necessary) but I add one that's 250px at the top, everything will appear to jump down 50px. So I guess the VBox would have to be placed in a Fixed and moved up 50px to prevent this, but then it won't be stretched to the ScrollWindow's size anymore… – Theophrastus

You could try to scroll manually to the current widget. – Ebby

Yes, but I think this would clash with the user interaction: when the scrollbar is being grabbed and pushed upwards (so that new widgets have to be added) it would feel weird if it suddenly jumped down. So I'll have to shift the widget's container. Or create an Adjustment adapter that can have a hidden offset. Maybe not using scroll bars at all, but something like a jog-dial, as Google Wave did? (is there a good widget for this already?) – Theophrastus

If you only wanted to extend the list to the bottom, then you could just add new widgets when the user stops scrolling near enough the bottom. The requirements are quite complex: you don't want the scroll bar to jump when a user drags it down, but if a user holds on to the scrollbar waiting for data to load, it should load. If you're looking to add data top and bottom, I don't see a scrollbar working well. Maybe stylised arrows above and below the list? (make sure mouse wheel events are handled in either case) – Prosaic

you're right, that would be the best way, messing with a jog-dail wouldn't work nicely with overlay-scrollbar and stand out as a non-native control… – Theophrastus

Years later and years after Android and others got recycler views we still have nothing useable? Really? – Draggletailed

Answer 1

If it is a infinity list, then you should not try to achieve anything with a scrollbar - this is only meant for finite lists.

My suggestion is to use an overlay with 2 buttons

+------------+
| UP ARROW   |
+------------+
| ITEM  N    |
| ITEM  N+1  |
| ITEM  N+2  |
+------------+
| DOWN ARROW |
+------------+

For the list between the buttons, you will probably have to implement a custom container widget yourself. I suggest to buffer n (>=2) widgets/items in each direction in advance.

Not really related to custom containers, but custom widgets - a starting point

http://zetcode.com/tutorials/cairographicstutorial/customgtkwidget/

http://gnomejournal.org/article/34/writing-a-widget-using-cairo-and-gtk28

http://old.nabble.com/Custom-container-%2B-Child-type-with-interface-td26863728.html

Enchilada