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

[Carl Nygard <cjnygard fast net>]

On Mon, 2002-09-30 at 11:48, Martin Schulze wrote:

I hesitate to jump in here, because I have no clue what Gst does (you're
wrapping Gstreamer right?).

BUT, I have a few observations from an outsider's perspective, and
perhaps (just perhaps) this might make sense.

After that singularly inspiring caveat, see comments below:

> The Gst::Object wrapper based on Gtk::Object is already done.
> It is based on Gtk::Object because GstObject and GtkObject (or better
> GtkWidget which adds the methods set_parent() and unparent()) behave
> _identically_ (apart from container destruction).
> And no, there isn't any problem. The following example code will work
> fine with gstmm, as soon as some more wrapper classes are available:
> (Gst::Bin is a container class for Gst::Object instantiations):
> 
> void test1()
> {
>    // my_pad won't be deleted until our reference is out of scope.
>    // Gst::RefPtr<> is identical to Glib::RefPtr<> but
>    // Gst::RefPtr<>::operator=() references and sinks the object.

Then it's not identical to Glib::RefPtr<>.  If you're going to use the
same naming convention, then (from a user's perspective) it better do
the exact same thing (at least semantically, if not technically).

If it doesn't do the same thing, then name it differently.

>    // => my_pad->ref_count == 1
>    Gst::RefPtr<Gst::Pad> my_pad = Gst::manage(new Gst::Pad);
> 
>    test2(my_pad); // first call to test2.
>    test2(my_pad); // second call to test2.
> }
> 

I may be dense, but if you use some arbitrary smart ptr, then you don't
need the Gst::manage() part, right?  I have no idea what you're doing
with my_bin, but your comments seem to indicate that my_bin only lives
within the scope of test2().


> void test2(const Gst::RefPtr<Gst::Pad>& pad)
> {
>    // Gst::Bin::add() increases the reference count of the new child.
>    // => my_pad->ref_count == 2
>    Gst::Bin my_bin;
>    my_bin.add(*my_pad);
> 
>    /* do something with my_bin */
> 
>    // On destruction, my_bin decreases the reference count of its children.
>    // => my_pad->ref_count == 1
> }
> 
> You have no chance getting this example code to work with gtkmm by
> replacing Gst::Pad with Gtk::Label and Gst::Bin with Gtk::HBox but
> to use a static object and not call manage, currently.
> No smart pointer could prevent the destruction of the label when
> function test2() ends.

On the other hand, if you're trying to use the same pad object in two
different hierarchies, then you're already violating Gtk idiom (I think)
which wouldn't allow the same widget to appear in two different widget
hierarchies
> 
> However, I will end this discussion now because nobody else pops up
> who seems to want that feature apart from me and because I had to
> notice that there are problems getting it to work for gtkmm.
> (basically only because of GtkButton with mnemonic that has a
> reference count of 2 after construction and thus can only be
> destroyed with gtk_widget_destroy() :-( )
> I'm sorry if you feel that I have wasted your time.

Of course, I could be totally wrong, in which case you might be better
served just ignoring me.

Regards,
Carl