Use the TREE_GRID, ROW, COLUMN_HEADER and GRID_CELL roles
for the various widgets involved in a GtkColumnView. To
enable this, we subclass GtkListView for the internal
list in the column view.
Now that both arguments to the _new_with_factory() constructors
are nullable, there's no good reason to keep a separate _new()
around. Just make gtk_list_view_new() and gtk_grid_view_new()
take both a model and a factory.
Change the apis in GtkListView, GtkColumnView and
GtkGridView to be explicitly about GtkSelectionModel,
to make it obvious that the widgets handle selection.
Update all users.
Make both gtk_list_view_new and gtk_list_view_new_with_factory
take a model as first argument, and make all arguments
allow-none and transfer full.
Update all callers.
Due to the many different ways to set factories, it makes sense to
expose them as custom objects.
This makes the actual APIs for the list widgets simpler, because they
can just have a regular "factory" property.
As a convenience function, gtk_list_view_new_with_factory() was added
to make this whole approach easy to use from C.
We now don't let the functions create widgets for the item from the
listmodel, instead we hand out a GtkListItem for them to add a widget
to.
GtkListItems are created in advance and can only be filled in by the
binding code by gtk_container_add()ing a widget.
However, they are GObjects, so they can provide properties that the
binding code can make use of - either via notify signals or GBinding.
Thisis the abstraction I intend to use for creating widgets and binding
them to the item out of the listview.
For now this is a very dumb wrapper around the functions that exist in
the API.
But it leaves the freedom to turn this into public API, make an
interface out of it and most of all write different implementations, in
particular one that uses GtkBuilder.
