chaining of destroy signal

[David Hampton]

On Mon, 2005-02-14 at 17:46 -0500, c.shoemaker at cox.net wrote:
> I'm pretty new to gobject and friends, but I feel like I'm picking it
> up ok.  There are, however, a few things that baffle me.  Here are a
> couple:
> ...
> In the code above, is it necessary to override the destroy signal and
> chain it to the parent class?  I would think that when the type system
> passes the GncTreeViewPriceClass to the class_init function,
> G_OBJECT_CLASS(klass)->destroy is already set to the parent's destroy
> function, right?  If the current object never refs any objects then we
> don't need to implement the destroy function at all, right?

Correct.  I tried to implement destroy functions on all objects for
consistence, and it makes life easier should something be added to
object in the future that requires destruction.  The runtime hit for
this code is only a handful of instructions.

> However, if this object can and does ref other objects, then we need
> to unref them in our own destroy function, before chaining to the
> parent's destroy function, right?  So, does this object take any refs?

Not that I remember.

> It goes:
> 
> >From gnc_tree_view_price_new():
> >  /* Create/get a pointer to the existing model for this set of books. */
> >  price_db = gnc_pricedb_get_db(book);
> >  model = gnc_tree_model_price_new (book, price_db);
> >
> >  /* Set up the view private filter on the common model. */
> >  f_model = egg_tree_model_filter_new (model, NULL);
> >  gtk_object_sink(GTK_OBJECT(model));
> >  s_model = gtk_tree_model_sort_new_with_model (f_model);
> >  g_object_unref(G_OBJECT(f_model));
> >  gtk_tree_view_set_model (tree_view, s_model);
> >  g_object_unref(G_OBJECT(s_model));
> >
> >  DEBUG("model ref count is %d",   G_OBJECT(model)->ref_count);
> >  DEBUG("f_model ref count is %d", G_OBJECT(f_model)->ref_count);
> >  DEBUG("s_model ref count is %d", G_OBJECT(s_model)->ref_count);
> 
> Doesn't the gtk_object_sink() call imply that we're becoming
> responsible for the remaining ref to model?  If so, does that mean
> we'd need do something like:
>  g_object_unref(G_OBJECT(gtk_tree_view_get_model(tree_view)))
> 
> in the destroy function?

When the model is created it is created with an initial reference.  Once
the gnc_tree_model_price has been added to the egg_tree_model_filter
(which adds its own reference) this initial reference can and should be
dropped so that the gnc_tree_model_price will be destroyed when the
egg_tree_model_filter is destroyed.  I believe this could be changed to
a g_object_unref, but I'm not sure.  I know I counted references on this
at runtime and everything was correct.  It is definitely wrong though to
be calling a gtk_object_xxx function on something that is only based on
a g_object.  Lots of gtk_objects in gnucash-1.x were converted to
g_objects for 2.x, and bugs like this have slipped in.

David

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20050215/4b8de92e/attachment.bin