GObject reference counts

["muppet" <scott asofyet org>]

some time ago we had a discussion on this list about the life time of perl
wrappers for GObjects versus the lifetime of a GObject.  i don't exactly
recall the final decision, and am not entirely certain what the current
implementation does, but i'm bumping into it because it's different from the
old gtk-perl.


last night i was working on porting some stable gtk-perl code to gtk2-perl. 
the old code did something like this [1]:


sub do_config {
    my $self = shift;
    my %userwidgets = @_;
    # create a new Gtk::Dialog, pack the user widgets in with standard
    # ones, and interact.  set $ret to true if user clicks ok.
    $dialog->destroy;
    return $ret;
}

# app-specific wrapper
sub my_config {
    my $self = shift;
    my %custom_widgets = {
        hostname => Gtk::Entry->new,
        database => Gtk::Entry->new,
        username => Gtk::Entry->new,
    };

    # other setup

    if (not $self->do_config (%custom_widgets)) {
        return undef;
    }

    # extract information from the custom widgets.
    return map { $_, $custom_widgets->{$_}->get_text } keys %custom_widgets;

    # %custom_widgets goes out of scope and auto-destroys here, taking
    # the GtkWidgets with it.
}


when i ported this to gtk2-perl, the application segfaulted when trying to
extract information from the widgets after the do_config call[2].  this means
that the custom widgets got destroyed with the dialog, even though i still
had scalars pointing to them in the calling code.  that in turn means that
the dialog had the only references to the widgets.  [is this not correct?]

without a lot of research into the code, my intuition is that gtk-perl kept
a reference on the object so that it stayed alive as long as the perl scalar
referred to it, whereas gtk2-perl lost its scalar's reference to the object
when  the container sunk the widget's floating reference.


as a perl coder, i expect the widget to be alive so long as i have a scalar
that points to it.  any other perl object behaves that way.


what do you guys think?



[1] this is actually a gross simplification.  the code in question is part
of a RAD module aimed at letting developers with no gui experience create a
specialized type of application without writing gui code; you merely supply
a hash describing data and action relationships, and the module creates and
runs the gui for you.  because of this, the code winds up doing things
rather backwards at times, such as extracting information from dialog
widgets after the dialog has been destroyed.  and in that particular case,
in fact, it's another library module that creates the custom dialog widgets
from yet another description hash, so the app writer never sees the letters
G, t, and k.  pretty cool, actually, in a hackish sort of way.  ;-)  i aim
to rewrite this whole thing to get rid of the hackish nature and make it
more proper, but the reference counting problem seems legitimate.

[2] actually, it was intermittent.  sometimes it spewed warnings all over the
console the first time or two and then dumped core, other times it dumped core
the first time.  the end result was the same, though, it tried calling
gtk_entry_get_text on a widget that had already been freed.

-- 
muppet <scott asofyet org>