Re: [Re:[[gtkmm] technical question: GTKMM_LIFECYCLE]

[Paul Davis <pbd op net>]

>> "petitioning the GTK+ crowd to use gtk_object_unref()
>> instead of gtk_widget_destroy() in gtk_container_destroy(). then we'd
>> end up with a much more consistent and easy to think about toolkit."
>> 
>> The difference is in how the underlying libraries treat containers.  Gst
>> uses a pure Glib refcount model, while Gtk shortcuts around it and
>> assumes if it's in the container, destroy it, don't just unref it.  If
>> this were fixed in Gtk, Gtkmm would by extension do the same thing, and
>> magically everyone would be consistent.
>> 
>	Yes, I understand this point. The thing I don't understand is, "Why
>would I want to have the container 'manage' the lifetime of the object if is
>doesn't absolutely ensure the destruction of it?"
>
>	This, I think, is the point M.C. is trying to make also. I'm having a
>hard time grasping why I would not want the object absolutely destroyed if I
>surrendered the lifetime of the object to the container. Or, are you saying
>that you really don't want to surrender the lifetime of the object to the
>container; rather, you want the lifetime of the object to be determined by the
>lifetime of the container and the lifetime of any other references, whichever
>lasts the longest. If so, isn't this semantically different from the purpose
>of "manage" which is to absolutely surrender the lifetime of the object to the
>lifetime of the container?

yes, that is the purpose of "manage" as currently implemented, but its
predicated on the way GTK+ containers work.

the central question:

   Gtk::Foo *foo = new Foo;
   Gtk::Container *bar = new Container;

   bar->add (foo);
   ...
   delete bar;

   // is foo is still a valid C++ object a this point?

in many common GUI applications, there is no reason for foo to be
valid any longer - adding foo to bar was intended to allow bar to
manage its lifecycle, hence:

       bar->add (manage (foo));

works to make this explicit. for many people and situations, this is
exactly what you want to happen.

however, there are other cases where its not. in those cases, you want
to the lifetime of foo to be determined by the longest-lived reference
to it. if thats bar, fine. but perhaps its something else.

with GTK+'s current model, there is no way to do this. this isn't a
requirement of GObject, the underlying C object, its a design decision
implemented by GTK+. other GObject-using APIs can make a different
design decision that supports the "longest-lived reference" model and
GObject will support that too. but gtkmm doesn't because GTK+ doesn't.

i believe that GTK+ made a mistake in this design decision, but its a
mistake that i have to admit i have never been affected by in any way.

--p