Re: Unparenting from GtkWidget "destroy"

--===============3977251524016436321==
Content-Type: multipart/alternative; boundary="00000000000063e88e05e34ec39e"

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

On Fri, Jul 8, 2022 at 9:26 AM Baldvin Kovacs <[email protected]>
wrote:

> 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  7=
558)
>     g_warning ("Finalizing %s %p, but it still has children left:",
> 08d644c4a53 (Timm B=C3=A4der                 2016-12-07 14:05:34 +0100  7=
559)
>                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 (s=
ee
> for example GtkColorChooserWidget). Recently there was a lot of cleanup a=
nd
> widgets nowadays directly inherit from GtkWidget. That is the pattern I w=
as
> attempting to follow in my own application as well (it is cleaner: it
> doesn't expose internal implementations through public inheritance, namel=
y,
> 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 wer=
e
> trying to do custom widgets _and_ using them in a managed manner.
>

Can you share an example? Is your custom widget implemented in C owned by
something wrapped in gtkmm? Are you focused on gtk3 or 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. Gtk4 also got rid of Gtk::Container so the details of
exactly how you're eliciting this will be helpful.

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

<div dir=3D"ltr"><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"g=
mail_attr">On Fri, Jul 8, 2022 at 9:26 AM Baldvin Kovacs &lt;<a href=3D"mai=
lto:[email protected]">[email protected]</a>&gt; wrote:<br></=
div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bor=
der-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div=
 dir=3D"ltr">Andrew Potter &lt;<a href=3D"mailto:[email protected]" target=
=3D"_blank">[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 cla=
ss=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid =
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:gtkmm=
[email protected]" target=3D"_blank">[email protected]</a>&gt; wrote:</div=
><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border=
-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div><b=
r></div><div>2. Expose the destroy signal handler, and document that one ne=
eds 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 this a =
new warning? My initial thought is this should be a feature of Gtk::manage =
rather than making everybody hook destroy to unparent.</div></div></blockqu=
ote><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 lef=
t:&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 (wi=
dget), 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 style e=
ven in the core Gtk was to inherit from Box (see for example GtkColorChoose=
rWidget). 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&#39;t expose internal i=
mplementations through public inheritance, namely, that the internal struct=
ure of the widget is a box).</div><div><br></div><div>Out of the two custom=
 widget examples in=C2=A0gtkmm-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 man=
y people were trying to do custom widgets _and_ using them in a managed man=
ner.</div></div></div></blockquote><div><br></div><div>Can you share an exa=
mple? Is your custom widget implemented in C owned by something wrapped in =
gtkmm? Are you focused on gtk3 or gtk4?=C2=A0 I know I&#39;ve made some cus=
tom widgets and not seen this warning, though I&#39;m not certain they deri=
ved from Widget; I recall there is quite a bit of care put into handling co=
ntainers. Gtk4 also got rid of Gtk::Container so the details of exactly how=
 you&#39;re eliciting this will be helpful.<br></div></div></div>

--00000000000063e88e05e34ec39e--

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

--===============3977251524016436321==--