Re: [gtk-list] Tracking object deletion

[Owen Taylor <owt1 cornell edu>]

Kenneth Albanowski <kjahds@kjahds.com> writes:

> What's the proper way (if any) to get a function invoked when a GtkObject
> (or descendant) is being destroyed?

When discussing this, it's probably best to separate out what happens
now from what will happen in the future. What happens now is pretty
broken, so I'll restrict myself to Marius's proposed behavior.

As proposed, the destruction of a widget happens only when it's
reference count drops to zero, not when gtk_widget_destroy() is
called. (In fact, there is really no gtk_widget_destroy - it would
be just as a synonym for a function meaning "take this widget
structure off the screen and remove it from it's parent" - basically
"gtk_widget_unparent()". If no extra reference counts have been
added, this will reduce the reference count to zero and destroy
the widget.

So it would simply be incorrect to do anything that needed to refer
to the widget when the "destroy" signal is invoked - and so the
"destroy" signal is what you are looking for.

On the other hand, if Perl keeps a reference count to the widget,
it will never have a zero reference count, and thus never be
destroyed. (If a user doesn't want to have the object stick
around, then they shouldn't store a reference to it an a global
variable.)

Of course, the problem then becomes "what if an object has been
destroyed by forces beyond our control - what then?" For widgets,
this probably isn't much of a problem. If the corresponding X
window is destroyed, it should be treated as if gtk_widget_unrealize()
has been called. The widget still exists, but without an accompanying
X window.

The same thing basically goes for GdkWindow's - though it is 
a bit more tricky, since all operations are errors after the
X window has been destroyed. A language binding has basically
two options:

Keep a reference count on the object - after the X window is
destroyed, if the user can't detect that and still calls a
function on it, let GTK handle it. Unfortunately, the only thing
that GTK can do is print a warning message and return. (If
it crashes instead, that is a bug, and needs to be fixed). C's 
biggest failing from a modern point of view is not it's lack
of OO, it's its lack of exception handling. (If GTK attempted
to return errors, this could be improved, but it wasn't designed
that way) Perhaps g_return_fail could be redesigned to set
a error flag - then a language binding could check that flag
on all calls.

The other possibility is not to keep a reference count, but install a
callback when the object is destroyed. (This isn't currently possible
with GdkWindows, thought it is with GtkObjects.) Then the language
binding can use it's own judgement on operations on no-longer-valid
obects. 

But I still think that the first approach is better - when combined
with a way for users to check if GdkWindow/Pixmap is still valid or
not. It is the way you want to handle most objects - if the user keeps
around a reference in Perl to an object, it shouldn't be destroyed,
IMO. And thus its probably better to handle objects that are
destroyable by outside-forces in the same manner.

These issues come up with a vengeance when dealing with networked
objects. Substitute:

  X window => remote object
  GdkWindow => locale surrogate object
  Perl refernce to such => language specific reference to remote object

Normally CORBA doesn't keep a reference count so local surrogates may
become invalid. (But CORBA does have EH - which is a slight help) ILU
allows keeping of reference counts as an extension, which is handy for
many things (DCOM is similar, I think). But for networked objects, you
need a keep-alive callback for the clients holding reference counts,
since otherwise if the remote client dies silently, objects will never
be destroyed.

Wow, I really strayed off track. I guess the short answer is - for
now, use "destroy" and warn users off referring to the object in an
installed "destroy" handler. In the future, you probably shouldn't
have such a thing.

Regards,
                                        Owen

P.S.

While I'm on the subject, I'll bring up a related issue:

When should Marius's patches go in? (See his post a few weeks ago for
more details) It will break most existing apps in a few easy-to-fix
ways, and possibly in more subtle ways if they tried to do
sophisticated things. (But if they did so, they are probably broken,
since GTK can't do those sophisticated things now).

The looming specter is the release of the GIMP. It's probably better
to make the changes now, while the GIMP is (barely) prelease, then
break compatibility later. But the opposing view is: "things almost
work now for the GIMP, wait until later, to do things that might
introduce bugs"

Regards,
                                        Owen