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:
> Hi!
> 
> Thanks Murray, I liked this response much more than your previous ones
> because you clearly say where you think I'm wrong and I don't have to
> guess. Also it makes me see where we simply didn't understand each other.
> 
> 1) Test code that doesn't work with gtkmm and that won't ever work with
>     gtkmm. Yet it seems to be what you proposed earlier:

I'll get around to checking out your code eventually. Unfortunately I have
terrible connectivity at the moment and that's slowing me down.
Maybe you should add this to bugzilla so we don't forget about it.

> Am 01.10.2002 00:18 schrieb(en) Murray Cumming:
> > By the way, I really disagree with your re-implementation of the manage()
> > system in Gst::Object because
> > 1) manage() is for child widgets and GtkObjects are not widgets. This
> > would
> > confuse the definition of manage().
> > 2) You have said that you want manage() to work differntly with
> > Gst::Objects
> > than it does currently with Gtk::Objects.
> 
>    While the second point won't break anything because it will work like in
>    gtkmm if you add your objects to one container only and delete the
>    container (which is the most common scenario in gtkmm), I will think
>    about your first point.
>    At the moment I still believe that manage() is meant more abstract and
>    simply means "let the lifetime of my object be controlled by a reference
>    counting system so that it will be deleted when all references have gone
>    (especially the one of the container I fed with my object)".

No, that's what RefPtr<> is for. manage() is about destruction, not about
reference-counting. If you add a ref to a child widget it will  _still_ be
destroyed when the container widget is destroyed. So I still object strongly
to your use of manage() for something else. And I don't think you even need to
implement that kind of convenience stuff at this stage - I think it would be
best to keep things simple at first.

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




Murray Cumming
murrayc usa net
www.murrayc.com