Re: none

[Maciej Stachowiak <mjs eazel com>]

Tim Janik <timj gtk org> writes:

> On 13 Dec 2000, Maciej Stachowiak wrote:
> 
> > Tim Janik <timj gtk org> writes:
> 
> > I don't get it. Why is it better for authors of apps and higher level
> > libraries to each make up their own "destroy" signal than to put it in
> > GObject? I think destroy notification for non-GUI objects is going to
> > be needed fairly frequently.
> 
> i doubt that. the purpose of ::destroy is to break inter-object links
> nowadays, which is also why it can be emitted multiple times on objects and
> has nothing to do with the object going dead anymore.
> for non-GUI objects, proper ref-counting (without floating-hassle) usually
> gets you what you want, what do you need explicit destroy_this_object()
> fucntions for?
> 

I don't care about the object being explicitly destroyed so much as
finding out when it's going away. It's the notification, not the
destroy, that matters.

Holding a ref is not a substitute for finding out when the object is
going away.

Maybe we are talking past each other because when I say destroy
notification, I don't necessarily mean anything related to
`gtk_object_destroy', I just want to know when the object is exiting
the building so I can stop assuming it exists for whatever reason. I
can think of multiple places in Nautilus where we connect to "destroy"
signals of non-GUI objects and I think replacing that with a named
data item would be awkward and messy (especially since each client
that cares about the destroy would need it's own unique name).

I don't really see why GUI vs. non-GUI is a useful way of
differentiating here. Why is GtkAdjustment something that needs
destroy notification more than the equivalent in a non-GUI program?

 - Maciej