GtkObject ref counting [was: resize queuing]

[Marius Vollmer <mvo zagadka ping de>]

Owen Taylor <owt1@cornell.edu> writes:
>
> On a similar note, shouldn't widgets be ref'd and unref'd while
> a draw is pending so that they can't be destroyed in the
> meantime?

I think we should rethinkg the GtkObject reference counting discipline
in general.  I'm not very sure how it works right now, but here are
some vague ideas how things could be:

- a new GtkObject will be created with a reference count of
  zero. [this is not thread safe, but blends with the established
  convention.  It would be better to create it with a ref count of
  one, but that is a *major* API change.  Every Gtk program had to be
  carefully checked and tweaked.  (Guile/Gtk programs wouldn't notice
  this, of course, hehe ;-)]

- there is no gtk_object_destroy call.  Instead the lifetime of a
  object is solely controlled by its reference count.  When it is
  decremented to zero by gtk_object_unref, the object is destroyed
  *immediately* and its destroyed signal is emitted.

- there are no GTK_OBJECT_IN_CALL, GTK_OBJECT_NEEDS_DESTROY,
  GTK_OBJECT_IN_DESTROY flags (except mayb to manage the special
  "destroy" signal, but that should be purely internal to the object
  implementation).  When some code can't deal with a object being
  destroyed it has to increase the ref count.  Alternatively it could
  add a handler to the "destroy" signal and invalidate all references
  to that object when that signal is emitted.

- every GtkWidget is supposed to be linked to a parent when it is in
  use.  Widgets that don't have a obvious parent (like GtkWindow,
  anything else?) are linked into a pseudo root parent, that exists
  during the lifetime of the whole program and is only used to keep
  references to the toplevel widgets.

- the gtk_widget_destroy call unlinks the widget from its parent and
  does all necessary things to revert the widget to a state just like
  before the first gtk_widget_show, so that it does not get any events
  and isn't drawn.  I don't know what will be required to do this,
  maybe gtk_widget_unrealize is enough and we don't really need
  gtk_widget_destroy.  gtk_widget_destroy will *not* forcefully
  destroy the object or mark it in any way as needing a destroy.  When
  the parent was the last reference, it is destroyed, else it lifes on
  and could theoretically return to the screen.  So gtk_widget_destroy
  is probably the wrong name for this function, if we need it at all.

  But: what should happen to the children of a `destroyed' widget?

That's it.  While a signal is being emitted for a object, the ref
count is increased.  Widgets that sit in some queue like the redraw
queue do not get their reference count bumped for this.  Rather, they
romve themselves from this queue in their "destroy" handler.  When the
operation that they are waiting for in the queue becomes bogus
(because they are no longer part of the widget hierachy, or are
unrealized, etc), it should be obvious from the state they are in.

Makes sense?