Re: Unparenting from GtkWidget "destroy"

--===============6165726534157023100==
Content-Type: multipart/alternative; boundary="0000000000001155e005e34dab06"

--0000000000001155e005e34dab06
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Andrew Potter <[email protected]> ezt =C3=ADrta (id=C5=91pont: 2022. j=C3=
=BAl. 8., P,
17:30):

>
>
> On Fri, Jul 8, 2022, 4:01 AM Baldvin Kovacs via gtkmm-list <
> [email protected]> wrote:
>
>>
>> 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=C3=A4der                 2016-12-07 14:05:34 +0100  755=
8)
    g_warning ("Finalizing %s %p, but it still has children left:",
08d644c4a53 (Timm B=C3=A4der                 2016-12-07 14:05:34 +0100  755=
9)
               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

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

<div dir=3D"ltr"><div dir=3D"ltr">Andrew Potter &lt;<a href=3D"mailto:agpot=
[email protected]">[email protected]</a>&gt; ezt =C3=ADrta (id=C5=91pont: 2022=
. j=C3=BAl. 8., P, 17:30):<br></div><div class=3D"gmail_quote"><blockquote =
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px sol=
id rgb(204,204,204);padding-left:1ex"><div dir=3D"auto"><br><br><div class=
=3D"gmail_quote" dir=3D"auto"><div dir=3D"ltr" class=3D"gmail_attr">On Fri,=
 Jul 8, 2022, 4:01 AM Baldvin Kovacs via gtkmm-list &lt;<a href=3D"mailto:g=
[email protected]" target=3D"_blank">[email protected]</a>&gt; wrote:<=
/div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bo=
rder-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><di=
v><br></div><div>2. Expose the destroy signal handler, and document that on=
e needs to unparent children both from that, and in the destructor.</div></=
div></blockquote></div><div dir=3D"auto"><br></div><div dir=3D"auto">Is thi=
s a new warning? My initial thought is this should be a feature of Gtk::man=
age rather than making everybody hook destroy to unparent.</div></div></blo=
ckquote><div><br></div><div>Not really new:</div><div><br></div><div><font =
face=3D"monospace">08d644c4a53 (Timm B=C3=A4der =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2016-12-07 14:05:34 +0100 =C2=A07558) =C2=A0 =
=C2=A0 =C2=A0 g_warning (&quot;Finalizing %s %p, but it still has children =
left:&quot;,<br>08d644c4a53 (Timm B=C3=A4der =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 2016-12-07 14:05:34 +0100 =C2=A07559) =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0gtk_widget_get_name =
(widget), widget);<br></font></div><div><br></div><div>My hypothesis about =
why this didn&#39;t bother people so far: up until recently the normal styl=
e even in the core Gtk was to inherit from Box (see for example GtkColorCho=
oserWidget). Recently there was a lot of cleanup and widgets nowadays direc=
tly inherit from GtkWidget. That is the pattern I was attempting to follow =
in my own application as well (it is cleaner: it doesn&#39;t expose interna=
l implementations through public inheritance, namely, that the internal str=
ucture of the widget is a box).</div><div><br></div><div>Out of the two cus=
tom widget examples in=C2=A0gtkmm-documentation/examples/book/custom one is=
 a custom widget which does painting (and has no child widgets), and the ot=
her 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.</div><div><br></div><div>My first instinct was also to make it a fe=
ature of Gtk::manage. It is nontrivial though, if we want to keep these con=
straints:</div><div><br></div><div>1. We allow people to do all their destr=
uction work in the C++ destructor, including unparenting.</div><div>2. We k=
eep Gtk unmodified with respect to this behavior.</div><div>3. We keep Gtkm=
m offering both managed and unmanaged ownership management.</div><div>4. Th=
e implementation of a Gtkmm object does not specify in the contract which m=
odel that object can be used with.</div><div><br></div><div>I think these t=
ogether won&#39;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&#39;t =
really see the possibility of executing the destructor outside of the norma=
l C++ logic.</div><div><br></div><div>My gut feeling is that there&#39;s on=
ly the following solutions:</div><div><br></div><div>1. Change Gtk with res=
pect to this behavior.</div><div>2. Unsupport destructor-based finalization=
 in Gtkmm. Prescribe some mechanism=C2=A0for people to use for finalization=
, including unparenting children.</div><div>3. Expose the user this detail,=
 and have them deal with the possibility of different destruction orders.</=
div><div><br></div><div>Baldvin</div><div><br></div><div><br></div><div><br=
></div><div>=C2=A0</div></div></div>

--0000000000001155e005e34dab06--

--===============6165726534157023100==
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

--===============6165726534157023100==--