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.
Can you share an example?
The output:
** Message: 19:58:33.322: Unparanting cw_as_member from destructor.
(gtkmm-destroy-demo:433199): Gtk-WARNING **: 19:58:33.322: Finalizing gtkmm__GtkWidget 0x56203e9b82c0, but it still has children left:
(gtkmm-destroy-demo:433199): Gtk-WARNING **: 19:58:33.323: - gtkmm__GtkButton 0x56203e870620
** Message: 19:58:33.323: Unparanting managed_cw from destructor.
Is your custom widget implemented in C owned by something wrapped in gtkmm?
No, it's very, very simple. I'm implementing something similar as the color chooser widget, but my own, with different behavior and characteristics. And I started by first researching, what's the current pattern, so that I just do it the way others do. I was quite surprised to see that the documentation on the web shows a Widget -> Container -> Box -> ColorChooserWidget hierarchy, whereas in the code I found Widget -> ColorChooserWidget. Then I started researching the topic, and looked up from Git log when this was changed, and checked other widgets too. From that, I concluded that a recent cleanup happened in this respect, and nowadays I'm not supposed to unnecessarily inherit from Box. (Also, I realized that I should build my on documentation from the actual repo I'm working from :) ).
Are you focused on gtk3 or gtk4?
I'm working from git head (gtk4).
I know I've made some custom widgets and not seen this warning, though I'm not certain they derived from Widget; I recall there is quite a bit of care put into handling containers.
The key to avoid this is to never use the parenting/unparenting of widget from C++ code. So as long as you inherit from Box, or a similar container, you're good. Then the unparenting is handled in C-land.
Gtk4 also got rid of Gtk::Container so the details of exactly how you're eliciting this will be helpful.
I _think_ the above text explains, but I'm not sure, please let me know if there are unclear details. Thank you!!!
Baldvin
