On Fri, Jul 8, 2022 at 11:10 AM Baldvin Kovacs <baldvin.kov...@gmail.com> 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.
_______________________________________________ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
