Include the base URI in the `g_test_bug()` calls instead. This resolves
inconsistencies between the old bug base (bugzilla.gnome.org) and the
new bug base (gitlab.gnome.org). It also has the advantage that the URI
passed to `g_test_bug()` is now clickable in the code editor, rather
than being split across two locations.
See https://gitlab.gnome.org/GNOME/glib/-/merge_requests/275#note_303175
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
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
Calling
g_list_model_get_item (store, 0);
g_list_model_get_item (store, -1u);
does not return NULL for the second call, as it should.
This was showing up in GTK+ list model tests.
It wasn’t being tested. It should behave the same as
g_list_model_get_item(), so write a wrapper for the two.
This brings the code coverage of glistmodel.c up to 100%.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
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
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
