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

[Murray Cumming <murrayc usa net>]

MHL Schulze t-online de (Martin Schulze) wrote:
> Did you understand the example I wrote in my mail? Is it not clear enough?

Your example was not an example of gtkmm code or an example of a
GstObject-not-deriving-from-GtkObject. However, I may have misunderstood about
the 2nd issue - see below.

> Do you doubt that you need to use the glib reference counter and not an
> extra reference counter of third party smartpointers when you want to
> stretch the lifetime of the underlying C object over the lifetime of
> its first container? Or what use do you think is a non-destroyed
> C++ wrapper when the underlying C instance has died?

I want to see test code. I've already responded to this question more than
once. I really will ignore you if you just repeat the question a 4th time.

> > I think it's a bad idea for the C++ wrapper's inheritance hierarchy to be
> > different than the underling C object's. I think it should be done
> > properly
> > and fixed appropriately _if a problem is found_. I absolutely will not
> > support
> > any wrapper that does something bizarre like this without first
> > demonstrating
> > that it is necessary. Your previous misunderstanding of the gtkmm
> > lifecycle
> > suggests that you really need to test your theory first instead of fixing
> > a
> > problem that might not exist.
> 
> What are you talking about? I know that my english is not perfect but
> I can't see where my text proposes that the inheritance structure of
> gstmm differs or will differ from the one of the underlying c library.

I thought that you said that Gst::Object would derive from Gtk::Object but
that GstObject derives from GObject. But I seem from you cvs web URL that that
is not true.

So I'll rephrase my position - I think you should check that your extra
lifecycle code in Gst::Object is necessary before implementing it, because it
doesn't look like you understood the default lifecycle code. I could be wrong
- but it should be clear by now that I only take time to fix or help to fix
problems that have been proven to exist. 

> Nor do I know what misunderstanding you mean. I did do some guesswork
> at first because I didn't fully understand _why_ certain things are done
> but I can't remember being proven wrong anywhere in _how_ things are done.

I disagreed about your understanding of what happens to the C and C++ objects
in certain situations. I know what's meant to happen because I wrote the code.
You have not yet supplied any test code that proves the existence of these
bugs, but there is lots of test code that proves that it works properly. I
believe that you misunderstood because you only looked at part of the code
without knowing the whole picture - but it would have been better to assume
that things work properly and only worry about a problem if you find it and
prove it.

> I hope the direct questions above will be more useful to make my point.
> The thing I was mistaken about was the fact that it is non-trivial to use
> Gst::RefPtr<> for gtkmm objects because of GtkButton.

By the way, GtkButton has just been changed (probably only in Gtk+ HEAD) so we
could go back to relying on that side-effect, but I'd prefer to keep the fix
that does things properly instead.




Murray Cumming
murrayc usa net
www.murrayc.com