widget.List with mixed underlying widget types

[hkparker]

As far as I understand it, the CreateItem function of a List should create a new placeholder instance of some widget, and UpdateItem should populate any instance of a widget with the correct data for the ListItemID. So far so good, that's all pretty straightforward.

However what if I want my list to container 2 or more different types of widgets? In that case my placeholder item would have to be either:

1. some super-widget that can display as either depending on what data you set in it, or
2. some empty max container, that gets filled during UpdateItem

Going with option 1 seems like the reliable choice, but is annoying / feels ugly.

Going with option 2 is clean and easy to write, I just always return a container.NewMax() for CreateItem, then with UpdateItem I place whatever widget I want in that max container and set the height. However, it stands to reason that the efficiency gains of List may somewhat come from the fact that these widgets aren't being re-created all the time. In that case, declaring a new widget every time UpdateItem is called and putting it in the container seems like potentially a big waste. I suppose I could also memoize the widget creation, and fill the max container with a pointer to the widget, which is stored in a separate data structure. At that point there shouldn't really be any additional costs.

Curious if the above makes sense. Does anyone have experience doing something like this, and were there any clever solutions? Also, how much does instantiating a new widget with every UpdateItem actually negate the benefits of using a List?

[Jacalz]

The ideal option is a modified version of 2. Create both widgets in the CreateItem function and hide them. In your UpdateItem function you show/hide them as required.

I think https://fynelabs.com/2022/12/30/building-complex-tables-with-fyne/ is useful.

[hkparker]

Alright so if I'm creating both then I need to package them up in some sort of fyne.CanvasObject. Could that be as simple as putting them in a VBox, then when doing UpdateItem, I:

1. check which one I want, based on the ListItemID
2. populate the data for the one that I want (which I can get by index in the Vbox's Objects)
3. Show the one I want, Hide the one I don't?

This is actually kinda like option 1, except that instead of having to make a new super widget, it's just a VBox.

[Jacalz]

You can just use a container.NewStack() (same as Max but that one is deprecated). You don't need a VBox. The widgets will render on top of each other but because only one is shown, you only see that one (and the other ones are not rendered so they don't slow things down).

[hkparker]

Cool. The issue I see with that is that I'd be instantiating one of each type of widget I want to support in the list with every CreateItem. Right now that's two, and these lists could be hundreds of thousands of items, so if I ever want to add a third or fourth widget I have to consider the memory footprint that would come with having a bunch of these "useless" widgets laying around. I'm not sure how many times CreateItem is called for a List, or if the size of that list has any impact on that. If the total number of created items for any List is small and constant, this isn't a real issue.

What makes sense to me is to have CreateItem return a stack container, and separately keep a slice of all the widgets I want to put in the list (of any number of types, stored as []fyne.CanvasObject). Then I can have UpdateItem look up the widget that is at that index in the slice and place it in the stack container that got passed in, and set the height. This seems to minimize re-creating anything or creating things that aren't used.

[Jacalz]

The CreateItem callback should, in theory, be called roughly as many times as you have items visible on the screen (maybe a few more times). Memory usage should hopefully not be impacted too much.

Before you try optimise things, make sure to benchmark it and not do any premature optimisation.

[andydotxyz]

What makes sense to me is to have CreateItem return a stack container, and separately keep a slice of all the widgets I want to put in the list (of any number of types, stored as []fyne.CanvasObject). Then I can have UpdateItem look up the widget that is at that index in the slice and place it in the stack container that got passed in, and set the height. This seems to minimize re-creating anything or creating things that aren't used.

perhaps counter-intuitively this will be slower. Our internal re-use system is more efficient than an external cache that switches in and out - we have less work to do when something changes and it should avoid some of the re-layout that would be required with your proposed solution.

As @Jacalz says try it out or even benchmark it - you will find that what was posted on the Fyne Labs blog is very efficient even for huge data sets.

[hkparker]

Great, ok thanks for all the context it's all much appreciated. Benchmarking yes. I was hoping to get a little more understanding of list behavior before giving this a go, which I've now got.

It's a little difficult for me to imagine where reloading steps will be saved, because each chat bubble is going to be a slightly different size probably. So unlike the more normal intended use of List where each object is the same size, I'll be moving things around often. But I'll trust in the List and give this a try when I'm ready. Thanks again!

[andydotxyz]

Ah yes text is a special case. If you can avoid resizing something that is mainly text you may be at an advantage because we can't make those assumptions at the List level - but doing so could be super difficult.

[hkparker]

Yeah, I don't see how I could avoid resizing these and still preserve the UX I want. The good news is that, if I understand Lists correctly, I should only be resizing what's currently visible, which won't be that many chat bubbles and still should be very fast.