[Gtk2-perl-bugs] [Bug 161012] Feature Request: Gtk2::TreeIters should be able to store data

[<bug...@bu...>]

http://bugzilla.gnome.org/show_bug.cgi?id=161012
gnome-perl | Gtk2 | Ver: unspecified





------- Additional Comments From zb...@fo...  2004-12-11 13:29 -------
To answer your question, Torsten, putting something into the array reference
doesn't help me very much because I have to keep a copy of it around at least
until the iter is no longer valid.  Generally speaking, if I have that, then
there's not much point putting it into the iter, too.

Let's say I have a unique id number in the first usable element of the iter
array, and some other piece of data I'd like to put in the second.  In order to
do that, I'm going to need to create Perl variables to store that data for each
valid iter until it isn't valid anymore.  To keep them organized, I'd probably
use an array, with the unique ID as an index.  I could then put a reference to
the right element into the TreeIter.

But that doesn't help much, because the array must persist as long as the
TreeIter is valid, so why not just store only the index in the Iter, and get the
data back out of the array when you need it?

My problem is, I don't want to have to have that array in the first place.  In
some cases, when you're implementing a custom TreeModel, you want to be able to
display data that's already stored in a Perl data structure, so there's no
problem; you can just put references from there into the TreeIter.  It has to
persist anyway, because it's the actual data.  But other times (like the one's
I'm working with :o) you want to display data that's stored somewhere else, like
a SQL database.  If I have to take data out of the DB and put it into an array
to be able to refer to it from an Iter, then I'm duplicating my data, which I
don't want to do :o)

This doesn't really become an issue until you need more than just one integer to
uniquely identify a particular data point.  Sometimes it would be nice, or maybe
lead to performance enhancements, but as long as one integer is unique enough,
then the Model can still be made to work.

I think, though, that the C implementation of a GtkTreeIter (which I didn't know
about before) means what I want can't work unless Gtk itself is changed, since
there's no way to manage lifetime.

I don't suppose there's any way to sort of make a "custom" TreeIter?  Since it
isn't a GObject (or a GInterface), I guess probably not.  If I could do that in
either Perl or C, I'd be all set, I think.

This probably isn't the right place, but I'm going to mention what I'm thinking
about so I don't lose it :o)  As long as it's designed to behave like a real
GtkTreeIter, that is, as long as it has a stamp accessible through iter->stamp,
could I make my own "struct MyTreeIter" that has lifetime management and can
notify perl when it's going to go away, but still have it work correctly with
the GtkTreeView?

------- You are receiving this mail because: -------
You are the assignee for the bug.