Andrew Potter <agpot...@gmail.com> ezt írta (időpont: 2022. júl. 8., P,
19:45):
>
> On Fri, Jul 8, 2022 at 9:26 AM Baldvin Kovacs <baldvin.kov...@gmail.com>
> wrote:
>
>> Andrew Potter <agpot...@gmail.com> ezt írta (időpont: 2022. júl. 8., P,
>> 17:30):
>>
>>>
>>>
>>> On Fri, Jul 8, 2022, 4:01 AM Baldvin Kovacs via gtkmm-list <
>>> gtkmm-list@gnome.org> 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äder 2016-12-07 14:05:34 +0100 7558)
>> g_warning ("Finalizing %s %p, but it still has children left:",
>> 08d644c4a53 (Timm Bäder 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, 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.
>>
>
> 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-destroy-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 gtkmm?
>
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 care
> 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
_______________________________________________
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list
