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

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

Am 03.10.2002 09:08 schrieb(en) Murray Cumming:
> MHL Schulze t-online de (Martin Schulze) wrote:
> > 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?
>
> manage() is a gtkmm function.
>
> > It's not the fault of gtkmm or gstmm that gtk and gstreamer handle the
> > lifetime of their objects differently.
>
> But we can improve on that by making the difference clearer in our
> wrappers.
>
> > 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.
>
> SigC::manage() exists to support Gtk::manage() as far as I know.

Gtk::manage() could easily be implemented without SigC::manage().
I don't see any problem. But SigC uses manage() internally for its
own reference counting system.

> > 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.
>
> So, you want to be consistent with gtkmm. But the gtkmm maintainer says
> that
> what you are doing is not consistent with gtkmm. You could fix it by just
> changing the name of one of your functions. But no, you insist that you
> know
> best what is consistent with gtkmm. Or you think that inconsistency is OK
> because GTK+ lifetimes aren't exactly how you'd like them.

I didn't refuse to rename the functions. I just don't want to do it in this
early stage before it is clear that there might be a completely different
solution.
Anyway, this inconvinience is so small that I really don't understand why
you are beating this bush so heavily: It just _adds_ the _possibility_ to
use a smartpointer that shares the object with the gstmm containers. I
repeatedly explained that if you use manage() like you do in gtkmm, the
behaviour of gstmm is identical with the behaviour of gtkmm.

> If you don't use manage() then you fix the problem. I don't think that's
> so
> difficult.

Just removing manage() means that objects won't ever be deleted when a
container dies even if it holds the only reference. That's a bad idea.
Removing manage() and forcing the use of Glib::RefPtr<> on the user is
not sensible because we don't need to use Glib::RefPtr<>. This is different
from glibmm / any other wrapper whose objects in the underlying library
don't have a floating state.

> And again, I really don't think that it's a good idea to add
> this
> stuff before you've even released a normal gstreamer wrapper.

This stuff is already there. In theory it works. I don't think it's a good
idea to remove it before we can even test things thoroughly. It's not that
much code we are talking about.

Regards,

  Martin