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

[Christian Meyer <chrisime uni de>]

Sorry, wrong email address...

Am Fre, 2002-09-27 um 13.36 schrieb Martin Schulze:

> - 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?

well, that's also what I noticed. The _destroy_c_instance() method is on
crack (or maybe murray was ;-) )
Thing can be cetainly done more consistently. I had a closer look at it
last weekend and what I found out that it's far too compicated and there
are still many TODO's in the code.
Maybe we can work together on a better solution!

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

I don't know SigC, but let me comment on it...
 
> - 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. 

OK, that's what I also dislike about gtkmm. Seems like in SigC the
design is much cleaner!

>    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.

I only get that half-way.

> 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 ;)

Martin, i haven't access to my email. But whenever it allows me to fetch
them, I'll check what you've sent me so far (BTW, was the ElementHelper
class ok?!)

Greetings,
Christian