Unparenting from GtkWidget "destroy"

[Baldvin Kovacs <baldvin kovacs gmail com>]

Hello,

I found that currently it is not possible to implement a Gtk::Widget descendant that properly unparents its children in case it is used in managed mode.

gtk_widget_finalize will complain with g_warning ("Finalizing %s %p, but it still has children left:", gtk_widget_get_name (widget), widget);

The C++ destructor is running too late for this (destroy_notify_ is too late too).

gtk_widget_dispose emits a "destroy" signal, which is in perfect time, but it is neither handled, nor exposed by Gtkmm.

Exposing it (https://gitlab.gnome.org/baldvin.kovacs/gtkmm/-/commit/f3cc321f2ed59415827f4400117d89bce4a93994) makes it possible to write correct code (https://github.com/baldvin-kovacs/gtkmm-destroy-demo/blob/main/gtkmm-destroy-demo.cc).

This is a working proof of concept, but I'd like to ask your opinion, but it has costs, mostly in terms of documentation complexity and exposed (leaked) abstractions.

Unfortunately, guaranteeing that the C++ constructor is executed before gtk_widget_dispose is not an option for managed instances.

Even more unfortunately, by the time the Gtk::Widget destructor starts running, one must not emit signals anymore which a descendant class handles (by that time the descendant parts may be destructed, IIUC).

What remains (of those that I can think of):

1. Make GtkWidget be not pesky about still having children at the time of destruction. Just unparent them, and be done with it, without warnings.

I don't see drawbacks of this, but I can imagine that they added this warning to help C developers write less buggy code. Maybe an option would be to add a parameter to the GtkWidget C class, and when wrapped by the C++ Gtk::Widget, then set the parameter (with the meaning: do not warn for lingering children).

2. Expose the destroy signal handler, and document that one needs to unparent children both from that, and in the destructor.

What do you think?

Baldvin