David McCabe <[EMAIL PROTECTED]> writes: > I still have a problem though: the signals row_inserted and > row_deleted seem to get thrown even when my own handler code is > inserting and deleting. I want something that is only sent when the > view is modified by external things like drag and drop reordering, not > my own stuff.
Yes, you do have to be careful to avoid unwanted and possibly infinite recursion if you do bidirectional updates with your backing list updating the TreeModel and the TreeModel updating your backing list. (This issue isn't specific to gtk+ or pygtk. Unwanted recursion can be a problem when the Observer pattern is used if there are cycles in the subject-observer graph.) In general I think the best way to handle this kind of problem is to always do the updates in a single direction (if this is feasible). In this case that would probably require making all updates directly to the TreeModel and letting the 'row-inserted' and 'row-deleted' signal handlers be responsible for making the appropriate updates to your backing list. This may seem backwards, but it's actually very simple and easy to guarantee correct. Since you have subclassed list this would require that you implement the special container methods __setitem__() and __delitem__() and have them update only the TreeModel and not the backing list. The signal handlers would then make the appropriate updates to the list. I haven't tried this but it should be possible to make it work. If you have already implemented these methods to update both the backing list and TreeModel this might actually make the code more simple by dropping the backing list update. > And I still can't make heads or tails out of the drag and drop signals. Drag and drop in gtk+ doesn't seem to be well documented, and I don't really understand it either. The case where the dnd is inside a single widget or application is much simpler than the general case between two different applications because you don't have to deal with X selections. A nice example of dnd in a treeview was posted to this list at the beginning of November. You should be able to find it in the list archives. The signal is 'drag-data-received', but to make it work you have to do the appropriate set up with TreeView.enable_drag_model_source() and TreeView.enable_drag_model_dest() and then use DragContext.finished() at the end. The details were worked out by Walter Anger who kindly shared his sample code with the list. Unless you need to handle more general drag and drop than row reordering I think watching TreeModel changes is easier. _______________________________________________ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
