[gtkmm] technical question: GTKMM_LIFECYCLE

[MHL Schulze t-online de (Martin Schulze)]

Hi!

In the process of wrapping gstreamer a few questions regarding
the lifecylce management code of gtkmm popped up.

In the current implementation of Gtk::Object the following behaviour
doesn't seem to be 100% consistent (first scenario):

- Why do we force a gtk_object_destroy() in the c++ instance's dtor
  when it hasn't been manage()ed (i.e. referenced_ == true)?
  Why don't we ensure that we simply remove all the references that
  have been created from our c++ wrappers instead?

- gtkmm objects that were not manage()ed are reference counted non
  the less. However, when the reference counter reaches zero the
  c object is deleted but the c++ instance is not (only gobject_ is
  set to 0). I understand that this is necessary to allow for gtk
  objects on the stack. But is this behaviour compatible with smart
  pointers? In other words: shouldn't the c++ instance be deleted
  when the reference counter reaches zero and the object has been
  allocated on the heap?


Anyway, sigc++ seems to propose yet a different behaviour (second
scenario):

- Don't delete the c++ instance at all unless it is passed through
  SigC::manage() (== Gtk::manage()) thus ignoring the reference
  counter. This is what gtkmm currently does. But:

- SigC::manage() "activates" the reference counter. The Gtk::Object
  implementation, however, makes the reference counter being ignored
  for manage()ed objects. As I understand SigC::manage(), Container
  classes should just reference the object and set a "parent"
  field when it is added, and unreference the object and unset the
  "parent" field when it is removed or the Container dies. Nothing
  proposes that the destruction of the Container's children should be
  forced ignoring the reference counter like gtk/gtkmm currently do.

The second scenario is also consistent with what gstreamer does.
It is very likely that we will implement it in gstmm. And probably
it has become clear from my biased description of the second
scenario that I would also prefer this for gtkmm ;)


Regards,

  Martin