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 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 ___ 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 Wednesday 09 May 2007 22:43, Federico Mena Quintero wrote: > [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...] A while ago I hit the same problem. Suppose you are maintaining a summary field of a model (the SUM() of a column, for instance): you need to catch the "row-changed", "row-inserted" and "row-deleted" signals of your GtkTreeModel implementation. But in this case there's no way to access a valid row in the "row-deleted" callback. Thank to a Vivien Malerba's suggestion, I had to wrap the data to be summarized in a G_TYPE_BOXED derived type and to use its GBoxedFreeFunc to catch the deletion. No needs to unref, but having a still valid row in the "row-deleted" callback can save some trouble (at least in this case). -- Nicola ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
GObject extension propose (GContainer)
Hi all, I'm a GObject based libraries (for UI purpose and not) user and I often need a generic container to derive my own types. In my opinion, I think this generic container must be included inside the GObject library ... it could be used by a lot of derived libraries providing a common approach. I published my solution - that is, what I am currently using - on sourceforge. http://sourceforge.net/projects/gcontainer/ Is it a good idea? Is something planned in this direction? Am I totally wrong? I need feedbacks ... Nicola ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GObject extension propose (GContainer)
> On Thu, 15 Jun 2006, Fontana Nicola wrote: > > Hi all, > > > > I'm a GObject based libraries (for UI purpose and not) user and I often > > need a generic container to derive my own types. In my opinion, I think > > this generic container must be included inside the GObject library ... it > > could be used by a lot of derived libraries providing a common approach. > > > > I published my solution - that is, what I am currently using - on > > sourceforge. > > > > http://sourceforge.net/projects/gcontainer/ > > > > Is it a good idea? Is something planned in this direction? Am I totally > > wrong? > > > > I need feedbacks ... > > hi. your gcontainer-1.0.0 looks like an interesting approach to me, but > i'm not sure it's generally good to put that into stock libgobject. > the main reason is that container needs are probably pretty variable > out there (i've come across at least 4 different gobject container > implementations in free software projects i'm woorking on) and that > both, making too little assumptions in the child/container interface > isn't going to be very helpful, albeit making too many has the > same problem. Some time ago I've started a communication library based on libgobject and I feeled the need of two things: a base object with floating reference and a container. After some time, I started an experimental cairo canvas and I had the same needs. In both cases, no gtk dependency was requested. Briefly, I'm not talking about a container that cover all needs and tastes but instead about "moving the GtkContainer logic and complexity" from gtk to gobject, something similar to what was done for GtkObject and its floating reference. I wrote gcontainer with this in mind (the GContainerable interface is "compatible" with GtkContainer and GChildable with GtkWidget). Anyway, my solution presents some serious problems: I'm misusing the interface to hide as much technical details as possible to the implementing objects. I know it is a huge task but consider this as an idea or a long term project: I don't think to be the only one with these needs. > > i guess we could add a link to your project from the libgobject docs > (it should probably have a Contrib section), for people possibly looking > for a GObject container implementation. that way, gcontainer-1.0.0 gets > a chance of being reused and maybe extended to something generally > usefull for GObject applications out there. > > > Nicola > > --- > ciaoTJ Of course I'll be glad to have a link in the gobject documentation. Thank you for your availability. Nicola ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
GObject extension propose (GContainer)
Hi all, I'm a GObject based libraries (for UI purpose and not) user and I often need a generic container to derive my own types. In my opinion, I think this generic container must be included inside the GObject library ... it could be used by a lot of derived libraries providing a common approach. I published my solution - that is, what I am currently using - on sourceforge. http://sourceforge.net/projects/gcontainer/ Is it a good idea? Is something planned in this direction? Am I totally wrong? I need feedbacks ... Nicola ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
