Ref cycles would prevent Views from being destroyed. They would drop from \~60 to \~50 refs. That would also prevent websockets from closing.
Disposing unrefs everything, allowing them to be freed from memory however that had the cost of... losing reference to them and their children sometimes.
Now what?
After some debugging, I pinned it down to Gtk.ListBox#bind_model. We have to clear the binding when it's time to be disposed, but there's no appropriate stage to do that on as dispose or destroy won't ever be called because of it.
Instead, manually remove the binding when it's time to be disposed, by using the same hack as before. The difference now is that we gracefully allow the view and its children to be destroyed, giving also the chance to notice and debug memory leaks.
Why keep the hack?
I believe the current choices are:
1) Keep the hack but manually clear the binding (this PR)*
2) Remove the hack but stop using Gtk.ListBox#bind_model
I don't want to do (2), at least not right now. Exposing just the model and letting descendants to just add items to it, rather than overriding a bunch of methods.
* Another possibility would be to clear it when removing the pages, but... that's not always possible as we have to keep track of navigation view replacements and nested views
This should fix all the random segfaults
Why were we disposing?
Ref cycles would prevent Views from being destroyed. They would drop from \~60 to \~50 refs. That would also prevent websockets from closing.
Disposing unrefs everything, allowing them to be freed from memory however that had the cost of... losing reference to them and their children sometimes.
Now what?
After some debugging, I pinned it down to
Gtk.ListBox#bind_model. We have to clear the binding when it's time to be disposed, but there's no appropriate stage to do that on as dispose or destroy won't ever be called because of it.Instead, manually remove the binding when it's time to be disposed, by using the same hack as before. The difference now is that we gracefully allow the view and its children to be destroyed, giving also the chance to notice and debug memory leaks.
Why keep the hack?
I believe the current choices are:
1) Keep the hack but manually clear the binding (this PR)* 2) Remove the hack but stop using
Gtk.ListBox#bind_modelI don't want to do (2), at least not right now. Exposing just the model and letting descendants to just add items to it, rather than overriding a bunch of methods.
* Another possibility would be to clear it when removing the pages, but... that's not always possible as we have to keep track of navigation view replacements and nested views