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

[Chris Vine <chris cvine freeserve co uk>]

On Thursday 06 July 2006 17:06, Caleb Cullen wrote:
> 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?

You can avoid the recursion by providing a flag in the callback.  However, is 
there any reason why you didn't try connecting to the row-deleted signal, 
which you mentioned at the beginning?  It is the last one to be emitted.

Chris