The sorter is where the column view combines the sorters of
individual columns, as the user clicks on headers. To make
sorting take effect, the sorter needs to be associated with
a sort model underneath the model thats shown in the view.
This is a special-purpose, private sorter implementation which sorts
according to multiple sorters, allowing each individual sorter to be
inverted. This will be used with clickable column view headers - whenever
a header is clicked, that columns sorter is prepended to the list of
sorters, unless it is already the first sorter, in which case we invert
its order. No column can be in the list more than once.
This is a helper object for sorting. Also add
two implementations, GtkStringSorter for collating
strings, and GtkCustomSorter, which uses a GCompareDataFunc.
It compiles, and no longer crashes insantly. But more work needed.
These changes depend on Pango 1.46's introduction of listmodels, so we
depend on that now.
This uses a custom GtkColumnViewTitle widget. So far that widget is
pretty boring, but that will change once we added
resizing, reordering, dnd, sorting, hiding/showing of columns or
whatever UIs we want.
The ColumnView now allocates column widths first and then the individual
rows use the new layout manager which looks at the column allocations to
allocate their children.
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.
