GtkObject: double destroys

[Owen Taylor <otaylor redhat com>]

Michael Meeks <michael ximian com> writes:

> 	Anyway, so having read the GtkObject compatibility code, I'm
> slightly intrigued as to why it is neccessary to allow 'double
> destroys' ( as mentioned in the Changes-2.0 ). This seems rather like
> a big pain in the neck for porting large projects.
> 
> 	Would not removing the unset of GTK_OBJECT_DESTROYED in
> gtk_object_dispose, not provide a more pleasant compatibility path ?

Remember, while most of gtkobject.c is compatibility wrappers
GtkObject itself is not a compatibility wrapper. GtkObject still
provides significant functionality, in particular the float/sink
memory management.

For this reason, we won't be getting rid of GtkObject usage in
GTK+, and we need to make it do "the right thing", not
just "the most compatible thing".

The problem with the GTK_OBJECT_DESTROYED flag is that:

 - It was poorly defined to start with; what could you do 
   with a destroyed-but-not-finalized widget? What should
   go in destroy and what should go in finalize?
 - Nobody ever got it right (if a double destroy hurts
   you now, well, then method calls against the object
   in the destroyed state will segfault you.)
 - It was an easy way to segfault a language binding.

By redefining things so that ::destroy is not a state transition 
notification but a request to release references to external
resources, we :

 - remove the idea of having an "invalid" state for a widget,
   which makes things easier for the user of the widget.
 - remove the need for widget writers to feel guilty about
   not checking GTK_WIDGET_DESTROYED() all over the place.
 - make it possible to give a decent explanation of what
   you should do in ::destroy and what in finalize().
   [ 
     In destroy: reset the state of the widget to the point
      where it no longer has references to external object
      leaving the widget in a valid state.
     In finalize: free all memory
   ]

The fact that currently _all_ widgets are destroyed twice
is basically just there as a debugging tool. We'll add
an optimization at some point so that if a destroy happens
as a result of refcount => 0, and the object doesn't get
reincarnated, then it won't get destroyed _again_ before
finalization.
 
> 	Also, the comment in gtk_object_destroy:
> 
>     {
>       /* need to hold a reference count around all class method
>        * invocations.
>        */
>       g_object_run_dispose (G_OBJECT (object));
>     }
> 
> 	somewhat confuses me; since a reference isn't taken, is this a
> throwback to the equivilant 1.2 comment ?

Yeah, this looks like a leftover comment. The actual ref/unref is in
g_object_run_dispose. Feel free to commit a removal of the comment.

If you want to do a writeup of this, the best place is probably
in a section about converting GTK+-1.2 widgets in Havoc's
'intro to GTK+-2.0' document.

Regards,
                                        Owen