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

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

Am 02.10.2002 19:26 schrieb(en) Murray Cumming:
> MHL Schulze t-online de (Martin Schulze) wrote:
> > Am 02.10.2002 11:25 schrieb(en) Murray Cumming:
> > > > Do we want the gtk containers on destruction to force
> > > > the destruction of our objects
> > >
> > > Yes we do. That's what GTK+ does and that's what we wrap. We already
> > > default
> > > to the more C++-like behaviour so I don't see a need to add a 3rd
> system
> > > just
> > > yet. It's something that you could think about for gtkmm3 but it must
> be
> > > gtkmm-wide, not just for gstreamer.
> >
> > Okay. I will search the ml for Karls comments about manage() I have
> > in mind that tell something different about the meaning of manage().
>
> Well, he hasn't been involved with gtkmm2 development so I don't see how
> that's relevant.

It's relevant in that it shows that there are different opinions about
this matter.

> > Meanwhile I can life with the policy in gtkmm as I have before.
> > However you must notice that gstmm must be different because
> gstreamer's
> > containers don't force the destruction of their children. Since the use
> > of boost::shared_ptr<> doesn't work with unmanage()ed objects I will
> > keep things like I have implemented them at the moment and recommend
> > users to write "Gst::RefPtr<Gst::Pad> my_pad = Gst::manage(new
> Gst::Pad);"
> > (or whatever the smartpointer will be named) if they want the lifetime
> > of their objects to be controled by a reference counter.
>
> Basically, you need to ask yourself whether you can live with me adding
> this
> sentence to the gtkmm FAQ about manage():
> "Please note that the gstreamer C++ bindings use a manage() function, but
> that
> that function does not do the same thing as Gtk::manage(). The gtkmm
> developers think that is a bad API decision in the gstreamer C++
> bindings."
>
> Personally, I'd prefer not having to say that.
>
> And note that you are not just adding a Gst::manage() function so you
> can't
> pretend that it is clearly separate. The way that you've coded it,
> Gtk::manage() and Gst::manage() are interchangeable - but Gst objects
> would
> not behave as expected when used with Gtk::manage().

You insist that gtkmm should work the way gtk does when the objects are
manage()ed.
Why then do you expect me to make gstmm work differently than gstreamer
with manage()ed objects?
It's not the fault of gtkmm or gstmm that gtk and gstreamer handle the
lifetime of their objects differently.

By the way there is also SigC::manage() which is interchangeable with
Gtk::manage() but the objects do not behave as expected when used
with SigC::manage(). SigC::manage() clearly has nothing to do with
forcing the desctruction of objects when their container dies.
So I could add to the gstmm FAQ that gstmm is doing the right thing
about manage() and that the gstmm developers think that it is bad a
API decision in the gtkmm C++ bindings to blindly follow the gtk
dictate whilst it could be handled differently without breaking anything.

Regards,

  Martin