Re: row-changed handler treepath lifespan

[muppet <scott asofyet org>]

On Jul 6, 2008, at 8:19 PM, Kevin Ryde wrote:

> Is the treepath allowed to be kept and used later outside the signal
> handler?  I know iters have bizarre lifespan rules, but I thought
> treepaths were ok (or as ok as anything in the path/iter/model debacle
> can be said to be ok! :-).

GtkTreePath is not a reference-counted object in C, but a plain old  
opaque thing.  When the C code destroys the path, it goes away.  Since  
you're getting this path from a signal invocation, it's not yours, and  
you can't keep it.

All you really have to do is make a copy, e.g. $global_path = $path- 
>copy().

Yes, it does suck.  This sort of boxed bug is one of the few places in  
Gtk2-Perl where you still have to think about memory management.   
Because of how GtkTreePath is implemented, there's no way for the perl  
wrapper to know that the object has been destroyed.

If i could change this without breaking lots of code, i'd rework the  
bindings for GtkTreePath not to be a normal opaque boxed wrapper, but  
actually return to perl the string representation of that path, and  
create a GtkTreePath from the string on demand in the bindings.  That  
would let you just give indices to the TreeModel API, which is what  
you really want to do anyway.

At the very least, might some operator overloading magic help?



--
The Master in the art of living makes little distinction between his  
work and his play, his labor and his leisure, his mind and his body,  
his education and his recreation, his love and his religion. He hardly  
knows which is which. He simply pursues his vision of excellence in  
whatever he does, leaving others to decide whether he is working or  
playing. To him he is always doing both.

  -- Zen Philosophy