Torsten Schoenfeld <kaffeeti...@gmx.de> writes: > > If you do, however, call $label->parent, then the marshalling code sees > that the underlying GObject has a floating reference and takes over > ownership of it (without adding a new reference). The GObject now has > two references to it, one from $self and one from $parent. With the > change under discussion, both of these get removed when INIT_INSTANCE > exits, leading to the destruction of the GObject.
Hmm, yes, bad. > So I have to ask: why are you calling $label->parent in INIT_INSTANCE > instead of simply using $self? I had two cases. The first was merely sharing some code by calling an "update_some_bits()" which would normally come out of a child signal handler, but I called it from the parent INIT_INSTANCE because it did what I wanted. The second I struck later was under SET_PROPERTY of the initial property settings as from ->new(foo=>123). I propagate a parent property to the child, as a form of "delegate", and in the child I had a "notify" signal handler coming back and updating some display bits in the parent, and to get the parent it used $self->parent. This isn't a circular update, since the parent bits were like "output only" reflecting the child state when it changed either by program code or user interaction. I rearranged one of my INIT_INSTANCE to avoid that part of the problem, but I couldn't think any clean way to mangle the initial property settings mechanism and still have later child changes update the parent the way I wanted. I wondered that if almost anything returning the widget currently under construction would suffer this reference sinking trouble, not just $child->parent(). Dunno if there's much in Glib alone to construct a failing case by returning the object under construction, but with gtk there's lots of ways to return a widget. So if it's almost any return then that could make the problem rather subtle and rather hard to avoid for a naive widget writer. -- On Tuesday the Australian Literature department at the University of Sydney announced an important advance in the field: they found some. _______________________________________________ gtk-perl-list mailing list gtk-perl-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-perl-list
