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 _______________________________________________ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
