Re: Model/view ideas for GtkListBox/GtkFlowBox

[Alexander Larsson <alexl redhat com>]

On ons, 2013-10-23 at 13:16 +0200, Alberto Ruiz wrote:
> Hey Alex,
>
> I've been playing with this idea myself, have a look at this github
> repo[0], don't pay too much attention to the ListView widget, I'm
> pretty much replicating Gtk.ListBox for the sake of understanding how
> to implement such widget.
> I am trying to experiement with a "scalable" approach where you can
> have a large data set and a bound set of allocated widgets necessary
> to display in the scrolledwindow (and also to avoid new widget
> allocations while you scroll). Some people think this is a bit of an
> overkill so I don't want to get too deep into this discussion while
> it's still an experiment.

Its not overkill at all. It is exactly what you want, and something e.g.
Android always does for its views (its called view recycling there,
google for it [1]). Basically you will have a set of row widgets created
which are enough to fill the screen and then some. And when they go
offscreen we reuse them (with new data) when scrolling in new rows. This
means we can reuse widgets, avoiding using lots of memory for objects,
and avoiding constant creation/destruction of objects. 

> There is one thing that I'd like to discuss about the API that I
> designed there and it is the notion of the RowDelegate, which is an
> interface that requires GtkBin and points to a specific index (or row)
> of a GObjectSet (Data.List in the source).

I don't think forcing each row to implement a specific interface (or
even have a custom type) is the right thing. I mean, I think it will
often be the case that you'd do this, but I also think something simple
like a list with text should be able to just have a GtkLabel in the row
and binding e.g. the "name" property on the model to the "label"
property on the GtkLabel. I.e. first make the simple case simple (but
efficient/smart) and then the complex possible.

In a more complex situation you can create a custom row type with its
own properties you can bind. Or, you can use class templates and bind
model properties to child name (i.e. gtk_widget_get_template_child) + a
property name on the child. Or in the most complex cases you can use
GGBindingTransformFuncs or a raw callback that applies the model to the
row.

This kind of setup allows the view itself to handle a lot of the code
that otherwise each RowDelegate would have to do, like track minimal
model changes, only modifying the row widget properties that changed,
queue changes updates to one-per-frame, etc. Also, the view needs to do
part of this anyway for view-internal work like sorting and filtering
based on the model and its changes.

[1] Interesting links:
http://stackoverflow.com/questions/15912999/recycling-views-in-custom-array-adapter-how-exactly-is-it-handled 
http://www.google.com/events/io/2009/sessions/TurboChargeUiAndroidFast.html