Re: A quick question: GtkTreeIter and GtkTreePath

["muppet" <scott asofyet org>]

René Seindal said:
> I'm porting a gtk-perl application to gtk2-perl-xs and are currently
> fighting with GtkCLists and GtkCTrees.
>
> There are several ways of adressing an element in a list, but what are the
> differences and respective merits of Gtk2::TreeIter, Gtk2::TreePath and
> Gtk2::RowReference?

the GtkTreeIter is the preferred way of dealing with tree model nodes.  the C
code is designed so that you can declare GtkTreeIters on the stack, which is
faster than fiddling with the heap for small operations.  (in perl this
doesn't make sense, so we always get new GtkTreeIters on the heap (but the
perl heap is arguably faster than the normal C heap...))  the GtkTreeIter is
designed to be fast, but not permanent.  in fact, most iters are invalid as
soon as anything about the model changes.

the GtkTreePath is just a path through some data structure to a row, and it
can be converted to a string.  this string relationship is handy because if
you can convert it to a string, you can save it to text file and read it back
from one.  those from the MFC/java world will recognize this as serialization,
but i feel dirty mentioning it so i will stop there.  paths are also
invalidated by changing the model.

the GtkRowReference is just that, a reference to a row.  it would appear that
its entire purpose is to keep a pointer to the row that is valid no matter how
much the model changes (aside from deleting the row, of course).


you'd use an iter within a callback.

you'd pass a path to callback.

you'd store a row reference for long-lived access to a certain row.


(that's based on how i've seen them used and what i've read from the
documentation.  anybody who knows better, please correct me.)


> What's the point of having so many different ways of doing the same?

i can't really speak for the gtk developers, but i presume it's in the
interest of flexibility and full-featured-ness.

-- 
muppet <scott at asofyet dot org>