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

[Murray Cumming <murrayc usa net>]

MHL Schulze t-online de (Martin Schulze) wrote:
> I remember people complaining on the ml that they find memory
> management with Gtk::Object difficult to understand repeatadly.
> Give them the possibility to manage their objects with a smartpointer
> and they will happy - that's my opinion.

I don't see so many messages like that. gtkmm memory management is as simple
as memory management with any C++ class, except for those few classes that
_must_ be used via the RefPtr smartpointer. Plus, we have manage() to make it
even easier.

I'm getting really tired of repeating myself, but I will again: Given that
gtkmm classes are just like regular C++ classes, you can use any existing
smartpointer to help out with the management of them. Prove to me that you
can't (with test code) and I'll be more interested.

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

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.

> 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):

I was asking for proof of a problem when GstObject is wrapped in the obvious
way, not when wrapped in this strange way. And I certainly can't investigate a
project that doesn't seem to be available to me yet.

> 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() :-( )

Yes, that's how I discovered a couple of weeks ago that we were relying on
side-effects of unreference() to cause destruction. We really _should_ 
guarrantee destruction of manage()ed widgets. That's what manage() is all
about.


Murray Cumming
murrayc usa net
www.murrayc.com