On Wed, May 09, 2007 at 03:43:20PM -0500, Federico Mena Quintero wrote: > Is there a description of when/how a model should implement > ref/unref_node? I recall asking this to JRB many times, but the > semantics were never completely clear to me.
There are no clear rules for this, actually. Most simple models don't have a real use for this. The filter and sort models both use this mechanism to keep track of which levels to cache and monitor. Models which reference external objects might want to use it. A node is referenced when it is visible. In the rule all expanded nodes count as visible; all nodes which are in GtkTreeView's internal rbtree are referenced. How {ref,unref}_node are implemented really depends on the model and what it tries to achieve AFAIK. > [The row_deleted signal always comes from the model, which means "this > row is really gone". Why would callers later need to unref that > row-which-is-already-gone? The model will have freed the row's > resources by then...] It is indeed documented as working as such. There are plausible cases for a model user to access a node in its row-deleted callback. You might want to write to the object stored in the row during deletion, or see the other case mentioned in this thread -- I'm sure there are many more use cases. It is good that you bring this question up though, since it made me think again about these changes. I actually just found a small note in the documentation that deleted rows are not supposed to be unreffed -- something which was already convoluted in the code. Now I vaguely remember hearing about this before and that there are cases where not unreffing deleted nodes caused trouble (or something similar). I will hash this out first and try to find those testcases before further exploiting making modifications to the row-deleted sementics. thanks, -kris. _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list