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

[Murray Cumming <murrayc usa net>]

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.

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

If you don't use manage() then you fix the problem. I don't think that's so
difficult. 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. 


Murray Cumming
murrayc usa net
www.murrayc.com