GtkTreeStore foreach on row-inserted or row-changed or rows-reordered

["Caleb Cullen" <pandemix gmail com>]

The situation:
I have a flat (tabular) data model in a GtkTreeView.  I don't -need- the
tree-ness, because all I am displaying is a flat, ordered list.  (They are
recipe ingredients.)  I used a GtkTreeStore because it supports various
useful interfaces, and because it will allow me to create groupings in the
future with minimal effort.

I'd like the user to be able to drag the ingredients into any desired
order.  Because I display the index number of the ingredient, I'd like to
keep them updated so that they properly reflect the ingredient's index.

According to the (somewhat sparse) documentation for GtkTreeView, w.r.t.
reordering of rows (gtk_tree_view_set_reorderable), one can "listen in"
using connections to the "row-deleted" and "row-inserted" messages.

I don't connect to "rows-reordered" because my list is flat and
"rows-reordered" isn't emitted when top-level rows change order.  At least,
this is according to other posts I found as I was researching these issues.

At first I connected to "row-inserted" on my treemodel (a GtkTreeStore).
Each time it was received, I'd iterate through the model
(gtk_tree_model_foreach), each time grabbing the pointer I've stored in an
undisplayed column, in order to set all the indices of the objects to be in
order vis-a-vis the treemodel.  Since I'd like the display to update, I then
use gtk_tree_store_set and cast the model to a store. to set the cell on the
store to match the new value of the object that row refers to.

This sort-of worked.  I say that because as my foreach loop traverses each
row of the model, sometimes the pointer I retreive comes back as NULL.  But
on the screen everything is fine.

I found another email posting wherein someone complained of this very
problem, and said that his issue was resolved by connecting not to
"row-inserted" (since apparently that message gets sent before the
newly-inserted row is actually updated with any useful data), but instead to
"row-changed".  I dubiously tried this, but of course since I update the
datastore inside my loop, it emits a "row-changed" message of its own, and
everything ends up in a very tight recursive spiral of death.

Now, I could eliminate the index-number display, or I could re-work the
display of those numbers so that they actually come from another place -- a
custom cell-renderer that just counts from one, for instance.  And then I
could mine those values out of the model when it's time to store the real
data (since it needs index values).

But this seems like a major deficiency of the system being employed in these
widgets, when I can't iterate over the elements in a predictable way after a
change.  Am I doing anything in an obviously wrong way?

- Caleb
PS -- thanks for reading this far!