GNOME Bugzilla – Bug 613970
ListStore/TreeStore 2.0.x remove() again
Last modified: 2021-07-05 12:22:25 UTC
Created attachment 157122 [details] [review] second attempt ListStore/TreeStore remove() on gtk 2.0.x I realized what I posted before for ListStore and TreeStore remove() for gtk 2.0.x is not right in the rare case that the Store's normal stamp is 0 and thus doesn't indicate a zapping. New attempt below, looking at a "user_data" change.
This isn't really that reliable, either. If the user_data pointer is NULL, then you're stuck. In GtkTreeModel.xs, it looks like NULL is a perfectly valid value for user_data. The code in gtkliststore.c in gtk+ will explicitly set the stamp to 0 to indicate removal, so i'm inclined to say that 0 is not a valid value for a user's stamp.
Ah, oops, I see gtk_tree_store_init() avoids stamp==0, so it's only ListStore to worry about -- its gtk_list_store_init() doesn't avoid stamp==0. The user_data coming in shouldn't be NULL, it's the G_SLIST() thingie of the row being removed. But in any case in last bit of gtk_list_store_remove() if there's a next row then it's changed and if not then it's unchanged. Of course this is not general, it only has to be enough for the 2.0.x sources and that particular remove func.
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME?utf8=%E2%9C%93&filter=perl- Thank you for your understanding and your help.