Re: Unparenting from GtkWidget "destroy"
Baldvin Kovacs via gtkmm-list <[email protected]> Fri, 8 Jul 2022 20:10:24 +0200
| Newsgroups | gmane.comp.gnome.gtkmm |
|---|---|
| Message-ID | <CAAw7jajpsS++ahFjNUy23hk0JfR1-Pk-0X++MX36vd65DeTxiA@mail.gmail.com> |
--===============2394724886335748711== Content-Type: multipart/alternative; boundary="00000000000063bcd905e34f1e55" --00000000000063bcd905e34f1e55 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, 19:45): > > 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 o= f >>> 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 = 7558) >> g_warning ("Finalizing %s %p, but it still has children left:", >> 08d644c4a53 (Timm B=C3=A4der 2016-12-07 14:05:34 +0100 = 7559) >> 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, name= ly, >> 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 we= re >> trying to do custom widgets _and_ using them in a managed manner. >> > > Can you share an example? > 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-destro= y-demo.cc . Now I added the #if to make it compile and run without the exposed destroy signal. The output: ** Message: 19:58:33.322: Unparanting cw_as_member from destructor. (gtkmm-destroy-demo:433199): Gtk-WARNING **: 19:58:33.322: Finalizing gtkmm__GtkWidget 0x56203e9b82c0, but it still has children left: (gtkmm-destroy-demo:433199): Gtk-WARNING **: 19:58:33.323: - gtkmm__GtkButton 0x56203e870620 ** Message: 19:58:33.323: Unparanting managed_cw from destructor. > Is your custom widget implemented in C owned by something wrapped in gtkm= m? > No, it's very, very simple. I'm implementing something similar as the color chooser widget, but my own, with different behavior and characteristics. And I started by first researching, what's the current pattern, so that I just do it the way others do. I was quite surprised to see that the documentation on the web shows a Widget -> Container -> Box -> ColorChooserWidget hierarchy, whereas in the code I found Widget -> ColorChooserWidget. Then I started researching the topic, and looked up from Git log when this was changed, and checked other widgets too. From that, I concluded that a recent cleanup happened in this respect, and nowadays I'm not supposed to unnecessarily inherit from Box. (Also, I realized that I should build my on documentation from the actual repo I'm working from :) ). > Are you focused on gtk3 or gtk4? > I'm working from git head (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 ca= re > put into handling containers. > 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. > Gtk4 also got rid of Gtk::Container so the details of exactly how you're > eliciting this will be helpful. > I _think_ the above text explains, but I'm not sure, please let me know if there are unclear details. Thank you!!! Baldvin --00000000000063bcd905e34f1e55 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">= <div dir=3D"ltr" class=3D"gmail_attr">Andrew Potter <<a href=3D"mailto:a= [email protected]">[email protected]</a>> ezt =C3=ADrta (id=C5=91pont: = 2022. j=C3=BAl. 8., P, 19:45):<br></div><blockquote class=3D"gmail_quote" s= tyle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pad= ding-left:1ex"><div dir=3D"ltr"><br><div class=3D"gmail_quote"><div dir=3D"= ltr" class=3D"gmail_attr">On Fri, Jul 8, 2022 at 9:26 AM Baldvin Kovacs <= ;<a href=3D"mailto:[email protected]" target=3D"_blank">baldvin.kova= [email protected]</a>> wrote:<br></div><blockquote class=3D"gmail_quote" styl= e=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddin= g-left:1ex"><div dir=3D"ltr"><div dir=3D"ltr">Andrew Potter <<a href=3D"= mailto:[email protected]" target=3D"_blank">[email protected]</a>> ezt= =C3=ADrta (id=C5=91pont: 2022. j=C3=BAl. 8., P, 17:30):<br></div><div clas= s=3D"gmail_quote"><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 di= r=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 <<a href=3D"mailto:[email protected]" target=3D"_blank">gtkmm-l= [email protected]</a>> 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><br></div><div>2. Expose the destroy signa= l handler, and document that one 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 this a new warning? My initial thought is this = should be a feature of Gtk::manage rather than making everybody hook destro= y to unparent.</div></div></blockquote><div><br></div><div>Not really new:<= /div><div><br></div><div><font face=3D"monospace">08d644c4a53 (Timm B=C3=A4= der =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2016-12-07 14:0= 5:34 +0100 =C2=A07558) =C2=A0 =C2=A0 =C2=A0 g_warning ("Finalizing %s = %p, but it still has children left:",<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't bother people so far: up unti= l 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 = 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, nam= ely, that the internal structure of the widget is a box).</div><div><br></d= iv><div>Out of the two custom widget examples in=C2=A0gtkmm-documentation/e= xamples/book/custom one is a custom widget which does painting (and has no = child widgets), and the other is using C++ destructor based destruction mec= hanism. I assume that not many people were trying to do custom widgets _and= _ using them in a managed manner.</div></div></div></blockquote><div><br></= div><div>Can you share an example?</div></div></div></blockquote><div><br><= /div><div>The one I linked in the original email follows well the pattern I= have:=C2=A0<a href=3D"https://github.com/baldvin-kovacs/gtkmm-destroy-demo= /blob/main/gtkmm-destroy-demo.cc">https://github.com/baldvin-kovacs/gtkmm-d= estroy-demo/blob/main/gtkmm-destroy-demo.cc</a> . Now I added the #if to ma= ke it compile and run without the exposed destroy signal.=C2=A0</div><div><= br></div><div>The output:</div><div><font face=3D"monospace">** Message: 19= :58:33.322: Unparanting cw_as_member from destructor.<br><br>(gtkmm-destroy= -demo:433199): Gtk-WARNING **: 19:58:33.322: Finalizing gtkmm__GtkWidget 0x= 56203e9b82c0, but it still has children left:<br><br>(gtkmm-destroy-demo:43= 3199): Gtk-WARNING **: 19:58:33.323: =C2=A0 =C2=A0- gtkmm__GtkButton 0x5620= 3e870620<br>** Message: 19:58:33.323: Unparanting managed_cw from destructo= r.<br></font></div><div>=C2=A0</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 class=3D"gmail_quote"><div>Is your custom = widget implemented in C owned by something wrapped in gtkmm?</div></div></d= iv></blockquote><div><br></div><div>No, it's very, very simple. I'm= implementing something similar as the color chooser widget, but my own, wi= th different behavior and characteristics. And I started by first researchi= ng, what's the current pattern, so that I just do it the way others do.= I was quite surprised to see that the documentation on the web shows a Wid= get -> Container -> Box -> ColorChooserWidget hierarchy, whereas i= n the code I found Widget -> ColorChooserWidget. Then I started research= ing the topic, and looked up from Git log when this was changed, and checke= d other widgets too. From that, I concluded that a recent cleanup happened = in this respect, and nowadays I'm not supposed to unnecessarily inherit= from Box. (Also, I realized that I should build my on documentation from t= he actual repo I'm working from :) ).</div><div>=C2=A0</div><blockquote= class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px so= lid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail= _quote"><div>Are you focused on gtk3 or gtk4? </div></div></div></blockquot= e><div><br></div><div>I'm working from git head (gtk4).</div><div>=C2= =A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e= x;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"= ><div class=3D"gmail_quote"><div>I know I've made some custom widgets a= nd not seen this warning, though I'm not certain they derived from Widg= et; I recall there is quite a bit of care put into handling containers.</di= v></div></div></blockquote><div><br></div><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're good. Then the unp= arenting is handled in C-land.</div><div>=C2=A0</div><blockquote class=3D"g= mail_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 class=3D"gmail_quote"><di= v>Gtk4 also got rid of Gtk::Container so the details of exactly how you'= ;re eliciting this will be helpful.<br></div></div></div></blockquote><div>= <br></div><div>I _think_ the above text explains, but I'm not sure, ple= ase let me know if there are unclear details. Thank you!!!</div><div><br></= div><div>Baldvin</div><div><br></div><div>=C2=A0</div></div></div> --00000000000063bcd905e34f1e55-- --===============2394724886335748711== 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 --===============2394724886335748711==--