Re: Unparenting from GtkWidget "destroy"

--===============7192234874804433997==
Content-Type: multipart/alternative; boundary="0000000000005107a605e3621fa0"

--0000000000005107a605e3621fa0
Content-Type: text/plain; charset="UTF-8"

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

>
> The one I linked in the original email follows well the pattern I have:
> https://github.com/baldvin-kovacs/gtkmm-destroy-demo/blob/main/gtkmm-destroy-demo.cc
> . Now I added the #if to make it compile and run without the exposed
> destroy signal.
>
>
Oh I see, sorry; when I first clicked I thought it was just an update to
the examples folder of gtkmm.


> The key to avoid this is to never use the parenting/unparenting of widget
> from C++ code. So as long as you inherit from Box, or a similar container,
> you're good. Then the unparenting is handled in C-land.
>
>

It seems you're right; unparent() is suggested to be called from dispose,
and dispose is not exposed in glibmm. sigc++'s add_destroy_notify_callback
is definitely too late. Widget's destroy signal has existed prior to gtk4
but I see the gtkmm bindings are not wrapping it; nor is the signal
explicitly ignored, so I'm not sure why.
Beyond exposing the destroy signal, another approach might be adding a
virtual dispose method if there is some known problem with sigc++ at this
point in the object lifecycle.

Maybe Kjell knows there is a good reason to not expose signal destroy /
dispose in gtkmm? If so you'd have to settle for subclassing a container,
but otherwise I'd prefer all signals to be available.

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

<div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail=
_attr">On Fri, Jul 8, 2022 at 11:10 AM Baldvin Kovacs &lt;<a href=3D"mailto=
:[email protected]" target=3D"_blank">[email protected]</a>&g=
t; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0p=
x 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div d=
ir=3D"ltr"><div class=3D"gmail_quote"><div><br></div><div>The one I linked =
in the original email follows well the pattern I have:=C2=A0<a href=3D"http=
s://github.com/baldvin-kovacs/gtkmm-destroy-demo/blob/main/gtkmm-destroy-de=
mo.cc" target=3D"_blank">https://github.com/baldvin-kovacs/gtkmm-destroy-de=
mo/blob/main/gtkmm-destroy-demo.cc</a> . Now I added the #if to make it com=
pile and run without the exposed destroy signal.=C2=A0</div><div><br></div>=
</div></div></blockquote><div><br></div><div>Oh I see, sorry; when I first =
clicked I thought it was just an update to the examples folder of gtkmm. <b=
r></div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0p=
x 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><d=
iv dir=3D"ltr"><div class=3D"gmail_quote"><br><div>The key to avoid this is=
 to never use the parenting/unparenting of widget from C++ code. So as long=
 as you inherit from Box, or a similar container, you&#39;re good. Then the=
 unparenting is handled in C-land.</div><div>=C2=A0</div></div></div></bloc=
kquote><div>=C2=A0</div><div>It seems you&#39;re right; unparent() is sugge=
sted to be called from dispose, and dispose is not exposed in glibmm. sigc+=
+&#39;s add_destroy_notify_callback is definitely too late. Widget&#39;s de=
stroy signal has existed prior to gtk4 but I see the gtkmm bindings are not=
 wrapping it; nor is the signal explicitly ignored, so I&#39;m not sure why=
. <br></div><div>Beyond exposing the destroy signal, another approach might=
 be adding a virtual dispose method if there is some known problem with sig=
c++ at this point in the object lifecycle.</div><div><br></div><div>Maybe K=
jell knows there is a good reason to not expose signal destroy / dispose in=
 gtkmm? If so you&#39;d have to settle for subclassing a container, but oth=
erwise I&#39;d prefer all signals to be available.<br></div></div></div>

--0000000000005107a605e3621fa0--

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

--===============7192234874804433997==--