Also refactor the whole list item management yet again.
Now, list item APIs doesn't have bind/unbind functions anymore, but only
property setters.
The item factory is the only one doing the binding.
As before, the item manager manages when items need to be bound.
Require that items created with the manager get destroyed via the
manager.
To that purpose, renamed create_list_item() to acquire_list_item() and
add a matching release_list_item() function.
This way, the manager can in the future keep track of all items and
cache information about them.
It's all stubs for now, but here's the basic ideas about what
this object is supposed to do:
(1) It's supposed to be handling all the child GtkWidgets that are
used by the listview, so that the listview can concern
itself with how many items it needs and where to put them.
(2) It's meant to do the caching of widgets that are not (currently)
used.
(3) It's meant to track items that remain in the model across
items-changed emissions and just change position.
(2) It's code that can be shared between listview and potential
other widgets like a GridView.
It's also free to assume that the number of items it's supposed to
manage doesn't grow too much, so it's free to use O(N) algorithms.
This is mostly for dealing with proper anchoring and can be used to
check that things don't scroll or that selection and focus handling
properly works.
For comparison purposes, a ListBox is provided next to it.
The thing we're actually doing is create and maintain a widget for every
row. That's it.
Also add a testcase using this. The testcase quickly allocates too many
rows though and then becomes unresponsive though. You have been warned.
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.
<lookup>foo</lookup>
is now short for
<lookup>
<constant>foo</constant>
</lookup>
ie it looks up the object with the given name so it can then do a
property lookup with it.
This is the most common operation, so it's a nice shortcut.
A constant without a type is assumed to be an object. This is the most
common case and allows
<constant>foo</constant>
without requiring updates to the type whenever the foo object changes.
The sort of the sortlistmodel is now stable with respect to the original
list model.
That means that if the sorter compares items as equal, the model
will make sure those items keep the order they were in in the original
model.
Or in other words: The model guarantees a total order based on the
item's position in the original model.
We need to keep this data around for changes in future commits where we
make the sorting stable.
An important part of the new data handling is that the unsorted list
needs to always be dealt with before the sorted list - upon creation we
rely on the unsorted iter and upon destruction, the sorted sequence
frees the entry leaving the unsorted sequence pointer invalid.
This change does not do any behavioral changes.
This is an enum that we're gonna use soon and it's worth introducing as a
separate commit.
The intention is to have meaningful names for return values in
comparison functions.
Use a weak ref to invalidate bindings. Make sure that this happens
before creating any watches, so that notifies from the
watched expression about changes will not trigger set_property() calls
during dispose()/finalize().
Invalidating also ensures that the watches aren't removed, which can
trigger warnings if the watches are watching the object itself, and the
weak refs cannot be removed anymore.
Users provide a search filter and an expression that evaluates the items
to a string and then the filter goes and matches those strings to the
search term.
GtkExpressions allow looking up values from objects.
There are a few simple expressions, but the main one is the closure
expression that just calls a user-provided closure.
We were applying the pango version requirements inconsistently,
leading to different pango variables being taking from system
pango vs the subproject at times. Thankfully, meson detects
this and complains, so we can fix it.
