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

[Carl Nygard <cjnygard fast net>]

On Wed, 2002-10-02 at 17:35, Martin Schulze wrote:
> 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.

Then you should just throw up your hands and say "It ain't gonna be
consistent."  The base libraries are already inconsistent, so quit
trying to force it.

And if it's going to be inconsistent, then don't use the same function
names for wrapping different functionality.  There are different rules,
don't confuse the user with Gtk::manage() works this way and
Gst::manage() works that way.  Make it obviously different.