GNOME Bugzilla – Bug 553008
GtkTreeModel should should provide a "reset" signal
Last modified: 2016-06-08 04:29:42 UTC
I have written a custom TreeModel displaying the contents of a .NET Framework IBindingList. This is a common interface for all observable lists that fire events when items are added, removed or reordered. Such lists can be wrapped to TreeModels very nicely as you can keep the model in sync with the list. My problem is that these lists can also fire a "reset" event when the data in the list changes completly and a complete reload of the list would be faster than firing events for every moved or added item. For example this reset event is fired when the sort criteria for the list changes instead of a bunch of "ItemReordered" events. I am unable to handle these reset events from the list because the TreeModel cannot be resetted and therefore it cannot force GtkTreeView & co. to reload it completly. Passing the reset event to Gtk+ as lots of RowsReordered, RowInserted and RowAdded events is also not possible because the list does not notify me how the list has really changed; it just instructs me to reload the data. Would you accept patches implementing a "reset" or "reload" signal for the GtkTreeModel interface?
I think that a construction like this is really worth including. I am only not fully sure yet how exactly it should look like and behave. (Also from a compatibility standpoint, views that cannot handle the signal still need to work, so there has to be a fallback of some kind). There are some more changes and additions that I want to make to the model interface and currently my plan for this is to investigate these, propose on gtk-devel-list and then implement and introduce all together.
(In reply to comment #1) First, thank you very much for looking into this bug. > I think that a construction like this is really worth including. I am only not > fully sure yet how exactly it should look like and behave. Besides implementing it as a new signal, I thought about using the existing rows-reordered signal with a NULL-pointer being passed for the new-order array. > (Also from a > compatibility standpoint, views that cannot handle the signal still need to > work, so there has to be a fallback of some kind). That's a really tough point. If we're using rows-reordered with a null-pointer, I see no simple way to implement a fallback solution. If we decide to implement the whole thing as a new "reset" signal, there could be a "n_old_children" parameter. Now, if the view does not support the event, emulate it by 1. Calling emit_row_deleted for each old child row 2. Calling emit_row_added for each child Again, I really appreciate that you are looking into this! If there is any way I can help, just let me know.
In situations like these I've found it easiest to just gtk_tree_view_set_model() with a new model that has the new data. This is basically what the file chooser does when switching directories, for example.