Refactor g_list_model_items_changed

In my application, there are numerous scenarios like this:
A GListModel instance contains a series of child container objects, which hold a collection of grandchild objects. then show the child object data with a GtkColumnView / GtkListView, sometimes shown via property bindings and other times computed through functions.

In practice, modifying the properties of grandchild objects often occurs without adding or removing items in the GListModel instance. This fails to trigger event updates, leading to display issues where data doesn’t refresh properly. To address this, I’m considering refactoring the GListModel.items_changed signal by adding an update parameter to explicitly trigger event-driven UI updates.

void
items_changed (
  GListModel* self,
  guint position,
  guint removed,
  guint added,
  gpointer user_data
)
void
items_changed (
  GListModel* self,
  guint position,
  guint removed,
  guint added,
  guint modified,                 // New parameter for udpate
  gpointer user_data
)

GListModel::items-changed means the items themselves have changed, in other words the list now contains altogether different items in this range, in the sense of object identity.

It’s not GListModel’s job to signal updates in properties of the items it contains, when the items themselves stay the same. You need to use some other mechanism for the UI to get updated when the properties change, such as GObject property notifications or GtkExpressions.

1 Like

Aside from misunderstanding how the items-changed signal works, you also cannot change a signal handler signature: it’s part of the ABI, and any addition/removal is a break. It’s exactly like adding or removing a parameter from a function, except worse, as you don’t get any help from the C compiler.

Stop trying to make items-change adapt to your specific use of the GListModel API; use the API as it’s meant to be used, instead.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.