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
_______________________________________________
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Reply via email to