Re: Fixing the GtkTreeModel::row-deleted inconsistency

On Wednesday 09 May 2007 14:06, Kristian Rietveld wrote:
> Hi,
> In the past all GtkTreeModels used to emit the row-deleted signal *after* a
> node had been fully deleted from the internal data structures.  This means
> that it is not possible to get an iter to that node any longer.  When
> fixing up the GtkTreeModelSort and GtkTreeModelFilter long ago, it appeared
> that emitting row-deleted after deleting the node is troublesome.  These
> models implement their own reference counting (the ref_node and unref_node
> methods), and on deletion of a node some objects (GtkTreeView in
> particular) have to release their last references to the node.  For this
> they need the iterator, which is not available anymore.
> We ended up changing the sort and filter models to emit the row-deleted
> signal *before* deleting the nodes.  Later on people implementing their own
> GtkTreeModels with reference counting hit the same problem and at some
> point a note was added to the API documentation, saying that
> implementations of GtkTreemodel must emit row-deleted prior to removing
> the node.
> Currently this behavior is inconsistent in GTK+, as the GtkListStore and
> GtkTreeStore still emit row-deleted *after* deleting a node.  For the sake
> of consistency I would like to modify both models to also emit row-deleted
> before deleting a node.  This will also allow for other applications to
> release their references to objects in a model row before a row is really
> deleted.  It does however change the behavior if you are iterating
> through the model, the row in the process of being deleted will still be
> "visible", where it was "invisible" before.
> Any objections?  I intend to make this change before the 2.12 release.
> regards,
> -kris.

In gtk_list_store_remove() and gtk_tree_store_remove(), is it possible to:

- remove the row from the model
- call gtk_tree_model_row_deleted(), leaving the row data accessible with 
gtk_tree_model_get_iter() or with a new API method
- free the row data


I intent the row_deleted signal as "this row is really gone from the model", 
not from the universe: I think having a signal that tell you something 
happened without specifying the subject is quite useless.

If applicable, this will not break anything.

-- Nicola

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]