It's a GtkListItemWidget subclass that tracks the column it belongs to
and allows the column to track it.
We also use this subclass to implement sizing support so columns share
the same size and get resized in sync.
It's private, no APIs, we don't talk about it. But we will start using
it very soon, so we can do size request caching in columns and avoid
sizegroups...
We only create them in root/unroot (they should be created in
appear/disappear, but that vfunc doesn't exist yet), that way we can
avoid expensive work while the widget isn't used for anything.
This way, we can ensure it's always there when we need it (before the
item gets created) and gone when we don't (if some GC language holds on
to the item after we've destroyed the widget).
Instead of 6 vfuncs, we now have 3 and rely on the factory keeping track
of what it needs to do.
We're doing lots of dancing from one object to another here, but this
will hopefully get simpler with further commits.
This splits GtkListItem into 2 parts:
1. GtkListItem
This is purely a GObject with public API for developers who want to
populate lists. There is no chance to cause conflict with GtkWidget
properties that the list implementation assumed control over and
defines a clear boundary.
2. GtkListItemWidget
The widget part of the listitem. This is not only fully in control of
the list machinery, the machinery can also use different widget
implementations for different list widgets like I inted to for
GtkColumnView.
The demo shows creating ones own listmodel and using it to fill a grid.
I am totally getting the hang of React btw:
500 lines of logic with no UI code and 100 lines of GtkBuilder XML and
I get a sweet UI.
The widget mostly works out of the box, but some tweaking may be
necessary (in particular in the theme) and the gtk-demo changes might
require removing before this is production-ready.
This reverts commit 6a164ab306dad9096bde736c907494c71086d3c4.
The function was awkward and we now have only one caller again, so we
can fold it back into it.
Nothing really changes, because both ListView and GridView still keep
self->item_manager around, but it's set up to point at the base's item
manager.
This way we can slowly move things to GtkListBase that need the item
manager (like trackers).
- Handle anchor as align + top/bottom
This fixes behavior for cells that are higher than the view
- Add gtk_list_view_adjustment_is_flipped()
This should fix RTL handling of horizontal lists
- Fix scrolling
This should make scrolling more reliable, particularly on short lists
that are only a few pages long.
I couldn't come up with a better way to automatically inherit the scope
in the builder list item factory that didn't involve a magic
incantation in the XML file. And I do not want developers to know magic
incantations to do a thing that should pretty much always be done.
