Re: Fixing the GtkTreeModel::row-deleted inconsistency
On Tuesday 15 May 2007 10:37, Kristian Rietveld wrote:
It depends what you mean with remove the row from the model. If that
means unlinking the row from the model's data structures, then there's
not a nice way anymore to retrieve an iterator to access that row. And
if _get_iter() is still supposed to be working, all other model methods
should also work: you are much better off not removing the row in that
case :)
Yes, I meant unlink it from the model. Think about something like this:
gboolean
gtk_list_store_remove (GtkListStore *list_store,
GtkTreeIter *iter)
{
GtkTreePath *path;
GtkSequencePtr ptr, next;
g_return_val_if_fail (GTK_IS_LIST_STORE (list_store), FALSE);
g_return_val_if_fail (VALID_ITER (iter, list_store), FALSE);
path = gtk_list_store_get_path (GTK_TREE_MODEL (list_store), iter);
ptr = iter-user_data;
next = _gtk_sequence_ptr_next (ptr);
- _gtk_tree_data_list_free (_gtk_sequence_ptr_get_data (ptr),
list_store-column_headers);
+ list_store-removed_data = (GtkTreeDataList *) _gtk_sequence_ptr_get_data
(ptr);
_gtk_sequence_remove (iter-user_data);
list_store-length--;
gtk_tree_model_row_deleted (GTK_TREE_MODEL (list_store), path);
+ _gtk_tree_data_list_free (list_store-removed_data,
list_store-column_headers);
+ list_store-removed_data = NULL;
gtk_tree_path_free (path);
if (_gtk_sequence_ptr_is_end (next))
{
iter-stamp = 0;
return FALSE;
}
else
{
iter-stamp = list_store-stamp;
iter-user_data = next;
return TRUE;
}
}
/* This new API method gets values from the very last deleted row: no needs
for an iter arg */
void
gtk_list_store_get_removed_value (GtkListStore *list_store,
gint column,
GValue *value)
{
GtkTreeDataList *list;
g_return_if_fail (GTK_IS_LIST_STORE (list_store));
g_return_if_fail (column list_store-n_columns);
g_return_if_fail (list_store-removed_data != NULL);
list = list_store-removed_data;
while (tmp_column-- 0 list)
list = list-next;
if (list == NULL)
g_value_init (value, list_store-column_headers[column]);
else
_gtk_tree_data_list_node_to_value (list,
list_store-column_headers[column],
value);
}
Of course, this solution needs a private field in the _GtkTreeStore struct and
a new API function, but it does not break anything and provides what needed.
Anyway, I think moving gtk_tree_model_row_deleted() at the top is a better
solution, but if you want backward compatibility, well, what can you do?
I think row-deleted does specifiy you the subject, one of its arguments
is the path ...
Yes, but if I need some data from the model I must duplicate it.
I don't want to bother, I only want to highlight that the row-deleted signal
(from an application developer's point of view) is, at this moment, quite
useless. But maybe I'm short in fantasy ...
-- Nicola
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Fixing the GtkTreeModel::row-deleted inconsistency
On Wed, May 09, 2007 at 02:01:20PM +0200, Sven Neumann wrote: Wouldn't it make more sense to introduce a new signal row-delete and use that instead of changing the semantics of row-deleted? If that would have been done in the first place, then you wouldn't have said inconsistency now. Yes, I agree that this complete problem wouldn't exist if we had added a new signal. However, right now both the filter and sort models have been emitting row-deleted before deleting the row and the documentation has had the said note for quite some time now, so personally I prefer to fix up the list and tree store at this point. Later on we can then easily add a post-row-deleted if required. Moving the filter and sort models over to a pre-row-deleted would require patching up tree view and will break any object (views, models, etc) which create their own references to iterators and release those on row-deleted, plus all third-party models doing reference counting. I think such a change would be more troublesome from a compatibility point of view than the change of gtk_tree_model_foreach() (for just the list and tree store) as outlined in my previous mail. regards, -kris. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Fixing the GtkTreeModel::row-deleted inconsistency
On Thu, 2007-05-10 at 17:04 +0200, Kristian Rietveld wrote: 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. So in general - A node is referenced if it is within the scrolled-in area of the view. - A node is referenced if it is expanded, even if it is not within the scrolled-in area (i.e. everything which the rbtree mirrors is reffed). Is that correct? [Humm, toplevel nodes are always in the rbtree, I think. Does this mean that all toplevel nodes are always reffed?] I'd love to watch a little toy model that just keeps an int for each node, and printf()s the references for each node as they change. Then you could see if scrolling the view up and down indeed keeps only the required nodes reffed --- this would be good evidence that you can indeed implement a model which doesn't have all its data exploded in memory all the time. Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Fixing the GtkTreeModel::row-deleted inconsistency
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. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Fixing the GtkTreeModel::row-deleted inconsistency
Hi, On Wed, 2007-05-09 at 14:06 +0200, Kristian Rietveld wrote: 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. Wouldn't it make more sense to introduce a new signal row-delete and use that instead of changing the semantics of row-deleted? If that would have been done in the first place, then you wouldn't have said inconsistency now. But then I have to admit that I probably just don't know enough about the internals. Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
