David McCabe <[EMAIL PROTECTED]> writes: > No, the actual problem is that I'm still getting None out of > TreeModel. Take a look at this function: > > def reflect_view(self): > > print self > list.__delslice__(self, 0, len(self)) > print self > > for row in self.view.get_model(): > list.append(self, row[0]) > print self > > Notice the three instances of 'print self'. I have confirmed that my > _view_rebuild methon, which syncs the view with the model (when the > model is modified by my code), is not being run anywhere inside of > this function, only before it. The first time an item is added to the > list, here is the output from the three calls to print: > > ['Some List Item'] > [] > [None] > > Therefore, row[0] in that for iteration is None instead of 'Some List > Item'. Which is weird.
Sorry, you're right. It is weird. This seems to be almost certain to trip up everyone at some point. When the 'row-inserted' signal is emitted, the model frequently (always?) contains unitialized (empty) rows. The reason for this is kind of odd, but it's a logical consequence of the gtk+ C API. If you look at the C API, there's no way to add an initialized row to a TreeModel in one step. The available functions like ListStore.append() and ListStore.insert() add new uninitialized rows to the model and you must subsequently use ListStore.set() to set the column values in the row. This seems harmless, but gtk+ emits the 'row-inserted' signal as soon as the empty row is added and confusion and befuddlement ensues in the signal handlers. Because of this, the 'row-inserted' signal isn't very useful. Most of the time when you might think you want 'row-inserted' you actually want 'row-changed' instead. This will catch the ListStore.set() which almost inevitably follows an insert. Try changing your handler to be called on 'row-changed' instead of 'row-inserted' to see if that works better. Or you can leave the handler as it is and add a new 'row-changed' handler to set the correct row values when they are set in the model. There has been some discussion on a gtk+ mailing list about making an addition to the API to allow inserting and setting a model row in a single call rather than requiring two. The rationale was that filtered treeviews (coming in gtk+ 2.4) expose filter functions to a lot of unitialized rows so this requires extra tests in the filter functions. I wonder how backward compatibility might be maintained because current applications are already written to accomodate this gtk+ treeview idiosyncracy. Sorry about missing this simple point in my earlier responses. I was puzzled by this for some time. Usually that makes it easier to remember, but I forgot. _______________________________________________ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
