2. Expose the destroy signal handler, and document that one needs to unparent children both from that, and in the destructor.
Is this a new warning? My initial thought is this should be a feature of Gtk::manage rather than making everybody hook destroy to unparent.
Not really new:
08d644c4a53 (Timm Bäder 2016-12-07 14:05:34 +0100 7558) g_warning ("Finalizing %s %p, but it still has children left:",
08d644c4a53 (Timm Bäder 2016-12-07 14:05:34 +0100 7559) gtk_widget_get_name (widget), widget);
My hypothesis about why this didn't bother people so far: up until recently the normal style even in the core Gtk was to inherit from Box (see for example GtkColorChooserWidget). Recently there was a lot of cleanup and widgets nowadays directly inherit from GtkWidget. That is the pattern I was attempting to follow in my own application as well (it is cleaner: it doesn't expose internal implementations through public inheritance, namely, that the internal structure of the widget is a box).
Out of the two custom widget examples in gtkmm-documentation/examples/book/custom one is a custom widget which does painting (and has no child widgets), and the other is using C++ destructor based destruction mechanism. I assume that not many people were trying to do custom widgets _and_ using them in a managed manner.
My first instinct was also to make it a feature of Gtk::manage. It is nontrivial though, if we want to keep these constraints:
1. We allow people to do all their destruction work in the C++ destructor, including unparenting.
2. We keep Gtk unmodified with respect to this behavior.
3. We keep Gtkmm offering both managed and unmanaged ownership management.
4. The implementation of a Gtkmm object does not specify in the contract which model that object can be used with.
I think these together won't fly, one has to give. Reason: From #2 it follows that Gtk code can decide to initiate disposal. However, because of #3, I can't really see the possibility of executing the destructor outside of the normal C++ logic.
My gut feeling is that there's only the following solutions:
1. Change Gtk with respect to this behavior.
2. Unsupport destructor-based finalization in Gtkmm. Prescribe some mechanism for people to use for finalization, including unparenting children.
3. Expose the user this detail, and have them deal with the possibility of different destruction orders.
Baldvin
