Closed Therzok closed 1 year ago
It's expected that all references held on the widget will also be released; you should connect to the “destroy” signal if you hold a reference to widget and you wish to remove it when this function is called. It is not necessary to do so if you are implementing a GtkContainer, as you'll be able to use the GtkContainerClass.remove() virtual function for that. It's important to notice that gtk_widget_destroy() will only cause the widget to be finalized if no additional references, acquired using g_object_ref(), are held on it. In case additional references are in place, the widget will be in an "inert" state after calling this function; widget will still point to valid memory, allowing you to release the references you hold, but you may not query the widget's own state. You should typically call this function on top level widgets, and rarely on child widgets.
If we destroy a widget we should free the toggleref and we should dispose the toggleref too. Basically I think we should make Destroy
act like a normal .NET Dispose
would work - we suppress finalization and free the handle+signals.
All things considered - I do not think this change is a breaking change in semantics as the widget is essentially unusable once Destroy is invoked. All we're doing is changing our code to complete the cleanup a little bit earlier.
I would like to test this for a day or three locally to make sure it doesn't trigger new issues due to bad re-use of destroyed widgets.
🤣
Up for discussion. Should we do this on destroy? Should we also do it on dispose and also free the toggleref there?