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.
My first instinct was also to make it a feature of Gtk::manage. It is
nontrivial though, if we want to keep these constraints:
1. We allow people to do all their destruction work in the C++ destructor,
including unparenting.
2. We keep Gtk unmodified with respect to this behavior.
3. We keep Gtkmm offering both managed and unmanaged ownership management.
4. The implementation of a Gtkmm object does not specify in the contract
which model that object can be used with.
I think these together won't fly, one has to give. Reason: From #2 it
follows that Gtk code can decide to initiate disposal. However, because of
#3, I can't really see the possibility of executing the destructor outside
of the normal C++ logic.
My gut feeling is that there's only the following solutions:
1. Change Gtk with respect to this behavior.
2. Unsupport destructor-based finalization in Gtkmm. Prescribe some
mechanism for people to use for finalization, including unparenting
children.
3. Expose the user this detail, and have them deal with the possibility of
different destruction orders.
Baldvin
_______________________________________________
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list
