GNOME Bugzilla – Bug 660018
[pygi] GtkTreeIter inconsistency
Last modified: 2012-04-28 14:27:31 UTC
Created attachment 197406 [details] test case According to http://developer.gnome.org/gtk3/unstable/GtkTreeModel.html#gtk-tree-model-iter-next one would expect status = model.iter_next(it) to work to increase it, with status indicating whether it succeeded, but one needs to write it = model.it_next(it); status = it and model.iter_is_valid(it) On the other hand, status = model.iter_previous(it) works as documented. Testcase attached. Happens with gtk3-3.0.12-1.fc15.x86_64 and gtk3-3.1.92-1.fc16.x86_64.
This should work just fine in C. Reassigning to PyGObject for investigation.
Looking at the overrides, I can see this method for the TreeModel: def iter_next(self, aiter): next_iter = aiter.copy() success = super(TreeModel, self).iter_next(next_iter) if success: return next_iter But not for iter_previous(). This explains why you get an iter from the one and the status for the other. Removing this method would break some other things in the overrides, like the get_next() method for TreeModelRow and TreeModelRowIter. I'm not a PyGobject developer, so can't comment on the best way to solve this though.
iter_previous should be fix to work like iter_next and iter_next should return None if the iter is invalid so this would work: iter = model.iter_first() while iter: # do something with iter iter = model.iter_next(iter) if you needed to keep the invalid iter around this should work though I have never tested it: iter = model.iter_first() result = iter while result: # do something with iter result = model.iter_next(iter) technically passing the scope of the function without returning anything will always result in None being returned but we could be more explicit here for readers of the code.
Still an issue with pygobject 3.2.
Created attachment 212603 [details] [review] Add missing override for TreeModel.iter_previous()
http://git.gnome.org/browse/pygobject/commit/?id=d37680bb9390426f7f58ea3d352c3e5e2106e978
*** Bug 674968 has been marked as a duplicate of this bug. ***