Re: GtkWidgets, Who owns what?

[Tristan Van Berkom <tristan upstairslabs com>]

On Tue, 2014-11-18 at 01:05 +0900, Tristan Van Berkom wrote:
> On Mon, 2014-11-17 at 10:02 -0600, The Devils Jester wrote:
> > I'm sorry, Form is (I believe) a holdover term from using Visual Basic over
> > a decade ago.   I do mean Window when I say that.
> >
> > Most of those answers are what I expected except I am not sure what GTK
> > considers as holding a reference.
> >
> > From my understanding when a widget is created it initially has a reference
> > count of 1.
>
> No, that's indicative that you have indeed not read the documentation of
> GInitiallyUnowned.
>
> As I mentioned in the previous mail, GtkWidget is GInitiallyUnowned,
> which means it is initially created with no hard reference, and only
> a floating reference.
>
> Best,
>     -Tristan
>
> >   If you add it to a container, the container sinks that
> > reference  (so it's now at 0).  When the container is destroyed it calls
> > destroy on its children (which deletes them if the reference count is
> > zero).  If I float the reference count manually, then the widget (and it's
> > children if it's a container) won't be destroyed.

As an additional note, this is also a misconception of
gtk_widget_destroy().

gtk_widget_destroy() actually has no effect on the reference count, it
emits a signal which must be trapped by any code segment which holds a
strong reference to the said widget (this is the contract of any object
which holds a reference to a GtkWidget, it must unref at "destroy"
time).

A GtkContainer holds a strong reference to all of it's children, so
when a child is "destroyed", it is automatically removed from the
container (that's the container's responsibility) - removing the
child from the container in turn, releases the container's strong
reference to that child.

The "destroy" signal also results in "destroy" being emitted on
all of the destroyed container's children.

Note that any GObject cannot exist with a ref count of 0, an object
is disposed and finalized when it's ref count reaches 0.

Cheers,
    -Tristan

> > When you say holding a reference,  do you mean something that has manually
> > increased the reference count?
> > On Nov 17, 2014 9:33 AM, "Tristan Van Berkom" <tristan upstairslabs com>
> > wrote:
> >
> > > On Mon, 2014-11-17 at 09:01 -0600, The Devils Jester wrote:
> > > > I have some questions about various situations and whether or not GTK or
> > > my
> > > > program is responsible for freeing the objects/memory in these
> > > situations.
> > > > Situation 1:  I have a (visible) form, with a container, with a widget.
> > > I
> > > > close the form.  Are all the widgets (and the form) cleaned up?
> > >
> > > Normally yes, this of course depends on if you are just 'hiding' the
> > > window (afaik there is no such thing as a 'form'), or destroying the
> > > window.
> > >
> > > Also depends on whether you have any explicit refs to any of the
> > > children.
> > >
> > > > Situation 2:  I have the same as above, but the window is never shown, so
> > > > is never closed. However, gtk_main_quit() is called.  Am I responsible
> > > for
> > > > the cleanup of the window?  (And if I destroy the window manually, will
> > > it
> > > > clean up all of its children?)
> > >
> > > Yes you are responsible for destroying the window, and yes, normally it
> > > will clean up all children.
> > >
> > > > Situation 3:  I have a container, that has children, but that container
> > > is
> > > > never added to a form.  Am I responsible for cleaning up the container?
> > > > And, as above, if I destroy the container, will it clean up its children,
> > > > or am I responsible for that?
> > >
> > > Yes, you are responsible for g_object_ref_sink()ing, destroying that
> > > container and then unreffing it, this is an abnormal case, and yes
> > > it will clean up it's children.
> > >
> > >
> > > > Situation 4:  I have a container with children (as in Situation 3), but
> > > it
> > > > was added to a form at one point (and later removed).  Am I responsible
> > > for
> > > > that (are we back to Situation 3 at that point?)
> > >
> > > This depends if you held any explicit ref count to the container, if you
> > > did not, it will automatically free itself and it's children when you
> > > remove it from it's parent.
> > >
> > > > With those 4 situations, is the following the correct way to clean up any
> > > > of the objects that I am responsible for?
> > > >
> > > >         g_object_ref_sink(G_OBJECT(widget));
> > > >         gtk_widget_destroy(widget);
> > > >         g_object_unref(G_OBJECT(widget));
> > >
> > > This should work consistently yes.
> > >
> > > Widgets are GInitiallyUnowned, so their ownership is consumed by
> > > their parent widget when they are added to a parent.
> > >
> > > The exception to the rule is GtkWindow and it's derived classes, which
> > > is owned by GTK+'s toplevel window list, regardless of whether the
> > > window was ever shown or not, or shown and then hidden.
> > >
> > > Cheers,
> > >     -Tristan
> > _______________________________________________
> > gtk-app-devel-list mailing list
> > gtk-app-devel-list gnome org
> > https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
>
>
> _______________________________________________
> gtk-app-devel-list mailing list
> gtk-app-devel-list gnome org
> https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list