chaining of destroy signal
Chris Shoemaker
c.shoemaker at cox.net
Tue Feb 15 19:05:27 EST 2005
On Tue, Feb 15, 2005 at 06:39:26PM -0500, Stephen Evanchik wrote:
> On Mon, 2005-02-14 at 17:46 -0500, c.shoemaker at cox.net wrote:
>
> > >From gnc-tree-view-price.c:
> >
> > > static void
> > > gnc_tree_view_price_destroy (GtkObject *object)
> > > {
> > > GncTreeViewPrice *view;
> > >
> > > ENTER("view %p", object);
> > > g_return_if_fail (object != NULL);
> > > g_return_if_fail (GNC_IS_TREE_VIEW_PRICE (object));
> > >
> > > view = GNC_TREE_VIEW_PRICE (object);
> > >
> > > if (GTK_OBJECT_CLASS (parent_class)->destroy)
> > > (* GTK_OBJECT_CLASS (parent_class)->destroy) (object);
> > > LEAVE(" ");
> > > }
>
> This isn't necessary in the GTK2 .. however what I have been doing is
> overriding the dispose function whenever I encounter a destroy.
Ok, that makes some sense.
>
> I'm not an expert either, but I think destroy is meant to be overridden
> by instances of the object whereas dispose is an object implementor
> function.
I can see that it would be useful at times to connect to the destroy
signal (is that what you mean by overridden by instances?), but I'm
having trouble imagining why we would want to:
GTK_OBJECT_CLASS(klass)->destroy = gnc_tree_view_price_destroy;
which is effectivly what we do now. Maybe it's just wrong?
>
>
> > 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?
> >
> > 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?
> > 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?
>
> Not in the destroy function, in dispose which is where objects are
> supposed to unref anything that they hold refs to (that's paraphrased
> from an email I discovered.. I'll try and locate it.)
>
> Feel free to correct me if I'm wrong..
heh. blind leading blind, huh? No, I think you're right. From the
GObject API docs: "the dispose function is supposed to drop all
references to other objects, but keep the instance otherwise intact,
so that client method invocations still work. It may be run multiple
times (due to reference loops). Before returning, dispose should chain
up to the dispose method of the parent class."
I guess the sort of transition from GtkObject's destroy to GObject's
dispose is part of the migration to GTK2?
Thanks for clarifying. BTW, I'm curious how you generated
http://people.clarkson.edu/~evanchsa/DEPRECATED_SYMBOLS_LIST. If it's
pretty automated, I'd be interested in tracking the size of that list
as a function of time. Some quantifiable measure of progress, you know?
-chris
More information about the gnucash-devel
mailing list