gio/gliststore.c: In function ‘g_list_store_insert’:
gio/gliststore.c:272:30: error: comparison of integer expressions of different signedness: ‘guint’ {aka ‘unsigned int’} and ‘gint’ {aka ‘int’}
272 | g_return_if_fail (position <= g_sequence_get_length (store->items));
| ^~
gio/gliststore.c: In function ‘g_list_store_splice’:
gio/gliststore.c:482:21: error: comparison of integer expressions of different signedness: ‘gint’ {aka ‘int’} and ‘guint’ {aka ‘unsigned int’}
482 | for (i = 0; i < n_additions; i++)
| ^
Currently, there is no quick way to find whether and element is already
part of a list store, except for manually writing a for-loop and calling
`g_list_model_get_item()` and breaking when you find the item.
This is mostly just a small API addition to support this use case.
Fixes https://gitlab.gnome.org/GNOME/glib/issues/1011
Rather than storing it as an invalid value in last_position, store it as
a separate boolean.
This introduces no functional changes, but should fix some warnings from
MSVC.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/glib/issues/1500
Check for over- and underflow when manipulating positions.
This makes the sequence
g_list_model_get_item (store, 0);
g_list_model_get_item (store, -1u);
return NULL for the second call, as it should.
Closes: #1639
When setting the GListStore:item-type property we need to check the
GType is a GObject (or subclass). There was some explicit code for this,
but when actually testing it and looking at the code coverage, it turns
out that the GObject property type check coming from
g_param_spec_gtype() does everything we want, and the custom
g_critical() can never be hit. So turn it into an assertion.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
This is also faster, though I doubt anyone's able to measure it.
The previous code was a more complicted way to do the same thing and it
was likely written the more complicated way because it fell out commit
758d7073a9 when fixing
https://bugzilla.gnome.org/show_bug.cgi?id=795307
It inserted the new items one position after the given one and inserted all new items
at the same position resulting in the items being in the reverse order of the
input array.
It was decided to make these behavioural changes because this function has according to
https://codesearch.debian.net/search?q=g_list_store_splice only one real user (nautilus)
and it didn't do what one would expect from reading the documentation.
https://bugzilla.gnome.org/show_bug.cgi?id=795307
GListStore already has a g_list_store_insert_sorted function,
which can be used to keep the list sorted according to a fixed
sort function. But if the sort function changes (as e.g. with
sort columns in a list UI), the entire list needs to be
resorted. In that case, you want g_list_store_sort().
https://bugzilla.gnome.org/show_bug.cgi?id=754152
GListStore requires that item-type be derived from GObject, so specify
that the type of the item parameters is GObject so the functions can be
used via gobject-introspection.
Add a scope parameter for the callback used during insert_sorted.
Add g_list_store_insert_sorted() which takes a GCompareDataFunc to
decide where to insert. This ends up being a very trivial function,
thanks to GSequence.
https://bugzilla.gnome.org/show_bug.cgi?id=743927
GListModel is an interface that represents a dynamic list of GObjects.
Also add GListStore, a simple implementation of GListModel that stores
all objects in memory, using a GSequence.
https://bugzilla.gnome.org/show_bug.cgi?id=729351
