Unparenting from GtkWidget "destroy"

--===============8796003364163372460==
Content-Type: multipart/alternative; boundary="000000000000540b9105e3491ed5"

--000000000000540b9105e3491ed5
Content-Type: text/plain; charset="UTF-8"

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

--000000000000540b9105e3491ed5
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hello,<div><br></div><div>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.</div><div><br></div><div>gtk_=
widget_finalize will complain with g_warning (&quot;Finalizing %s %p, but i=
t still has children left:&quot;, gtk_widget_get_name (widget), widget);</d=
iv><div><br></div><div>The C++ destructor is running too late for this (des=
troy_notify_ is too late too).</div><div><br></div><div>gtk_widget_dispose =
emits a &quot;destroy&quot; signal, which is in perfect time, but it is nei=
ther handled, nor exposed by Gtkmm.</div><div><br></div><div>Exposing it (<=
a href=3D"https://gitlab.gnome.org/baldvin.kovacs/gtkmm/-/commit/f3cc321f2e=
d59415827f4400117d89bce4a93994">https://gitlab.gnome.org/baldvin.kovacs/gtk=
mm/-/commit/f3cc321f2ed59415827f4400117d89bce4a93994</a>) makes it possible=
 to write correct code (<a href=3D"https://github.com/baldvin-kovacs/gtkmm-=
destroy-demo/blob/main/gtkmm-destroy-demo.cc">https://github.com/baldvin-ko=
vacs/gtkmm-destroy-demo/blob/main/gtkmm-destroy-demo.cc</a>).</div><div><br=
></div><div>This is a working proof of concept, but I&#39;d like to ask you=
r opinion, but it has costs, mostly in terms of documentation complexity an=
d exposed (leaked) abstractions.</div><div><br></div><div>Unfortunately, gu=
aranteeing that the C++ constructor is executed before gtk_widget_dispose i=
s not an option for managed instances.</div><div><br></div><div>Even more u=
nfortunately, by the time the Gtk::Widget destructor starts running, one mu=
st not emit signals anymore which a descendant class handles (by that time =
the descendant parts may be destructed, IIUC).</div><div><br></div><div>Wha=
t remains (of those that I can think of):<br></div><div><br></div><div>1. M=
ake GtkWidget be not pesky about still having children at the time of destr=
uction. Just unparent them, and be done with it, without warnings.</div><di=
v><br></div><div>I don&#39;t see drawbacks of this, but I can imagine that =
they added this warning to help C developers write less buggy code. Maybe a=
n option would be to add a parameter to the GtkWidget C class, and when wra=
pped by the C++ Gtk::Widget, then set the parameter (with the meaning: do n=
ot warn for lingering children).</div><div><br></div><div>2. Expose the des=
troy signal handler, and document that one needs to unparent children both =
from that, and in the destructor.</div><div><br></div><div>What do you thin=
k?</div><div>Baldvin</div><div><br></div><div><br></div><div><br></div></di=
v>

--000000000000540b9105e3491ed5--

--===============8796003364163372460==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
gtkmm-list mailing list
[email protected]
https://mail.gnome.org/mailman/listinfo/gtkmm-list

--===============8796003364163372460==--