Re: Non-atomicity in gtk_list_store_insert(), gtk_list_store_set()
- From: Christof Petig <christof petig-baender de>
- To: Jonathan Blandford <jrb redhat com>
- Cc: Federico Mena Quintero <federico ximian com>, gtk-devel-list gnome org, Murray Cumming Comneon com
- Subject: Re: Non-atomicity in gtk_list_store_insert(), gtk_list_store_set()
- Date: Fri, 07 Nov 2003 09:55:02 +0100
Jonathan Blandford schrieb:
Federico Mena Quintero <federico ximian com> writes:
The idea is to call it like this:
gtk_list_store_insert_and_set (list_store, &iter, N,
0, "foo",
1, "bar",
-1);
This would make the insertion+modification atomic; the append_and_set()
version would be analogous. Only the "insert-row" signal would be
emitted.
A very good idea (also since iterator dereferences slow gtkmm down
considerably, there are similar patches
[http://bugzilla.gnome.org/show_bug.cgi?id=108816] floating around as a
remedy).
IIRC you missed the parent argument ...
Isn't append_and_set simply passing -1 for position - a separate
function would be overkill IMHO (though gtk+ tends to go that way)?
A GValue variant would be a good idea, too. Especially C++ people tend
to put (boxed) objects into ListStores.
Perhaps insert_before/insert_after are far more efficient (I don't know
the implementation details), so replacing them (too) would make it even
faster.
This function is probably fine to add. A couple comments:
* I am not really sold on the name. I think insert_with_values sounds
a bit better.
I like that name too.
* We also need a non-varargs version for language bindings.
GList?
Should we have this, and deprecate the old insert()/append() functions?
set() can remain in place, as it is needed to modify existing rows.
I'd rather not deprecate the old functions here. It doesn't buy us anything.
But a comment should tell the users to prefer the new variant because of
atomicity and speed.
Christof
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]