Re: GtkWidgets, Who owns what?
On Mon, 2014-11-17 at 09:01 -0600, The Devils Jester wrote: I have some questions about various situations and whether or not GTK or my program is responsible for freeing the objects/memory in these situations. Situation 1: I have a (visible) form, with a container, with a widget. I close the form. Are all the widgets (and the form) cleaned up? Normally yes, this of course depends on if you are just 'hiding' the window (afaik there is no such thing as a 'form'), or destroying the window. Also depends on whether you have any explicit refs to any of the children. Situation 2: I have the same as above, but the window is never shown, so is never closed. However, gtk_main_quit() is called. Am I responsible for the cleanup of the window? (And if I destroy the window manually, will it clean up all of its children?) Yes you are responsible for destroying the window, and yes, normally it will clean up all children. Situation 3: I have a container, that has children, but that container is never added to a form. Am I responsible for cleaning up the container? And, as above, if I destroy the container, will it clean up its children, or am I responsible for that? Yes, you are responsible for g_object_ref_sink()ing, destroying that container and then unreffing it, this is an abnormal case, and yes it will clean up it's children. Situation 4: I have a container with children (as in Situation 3), but it was added to a form at one point (and later removed). Am I responsible for that (are we back to Situation 3 at that point?) This depends if you held any explicit ref count to the container, if you did not, it will automatically free itself and it's children when you remove it from it's parent. With those 4 situations, is the following the correct way to clean up any of the objects that I am responsible for? g_object_ref_sink(G_OBJECT(widget)); gtk_widget_destroy(widget); g_object_unref(G_OBJECT(widget)); This should work consistently yes. Widgets are GInitiallyUnowned, so their ownership is consumed by their parent widget when they are added to a parent. The exception to the rule is GtkWindow and it's derived classes, which is owned by GTK+'s toplevel window list, regardless of whether the window was ever shown or not, or shown and then hidden. Cheers, -Tristan ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GtkWidgets, Who owns what?
I'm sorry, Form is (I believe) a holdover term from using Visual Basic over a decade ago. I do mean Window when I say that. Most of those answers are what I expected except I am not sure what GTK considers as holding a reference. From my understanding when a widget is created it initially has a reference count of 1. If you add it to a container, the container sinks that reference (so it's now at 0). When the container is destroyed it calls destroy on its children (which deletes them if the reference count is zero). If I float the reference count manually, then the widget (and it's children if it's a container) won't be destroyed. When you say holding a reference, do you mean something that has manually increased the reference count? On Nov 17, 2014 9:33 AM, Tristan Van Berkom tris...@upstairslabs.com wrote: On Mon, 2014-11-17 at 09:01 -0600, The Devils Jester wrote: I have some questions about various situations and whether or not GTK or my program is responsible for freeing the objects/memory in these situations. Situation 1: I have a (visible) form, with a container, with a widget. I close the form. Are all the widgets (and the form) cleaned up? Normally yes, this of course depends on if you are just 'hiding' the window (afaik there is no such thing as a 'form'), or destroying the window. Also depends on whether you have any explicit refs to any of the children. Situation 2: I have the same as above, but the window is never shown, so is never closed. However, gtk_main_quit() is called. Am I responsible for the cleanup of the window? (And if I destroy the window manually, will it clean up all of its children?) Yes you are responsible for destroying the window, and yes, normally it will clean up all children. Situation 3: I have a container, that has children, but that container is never added to a form. Am I responsible for cleaning up the container? And, as above, if I destroy the container, will it clean up its children, or am I responsible for that? Yes, you are responsible for g_object_ref_sink()ing, destroying that container and then unreffing it, this is an abnormal case, and yes it will clean up it's children. Situation 4: I have a container with children (as in Situation 3), but it was added to a form at one point (and later removed). Am I responsible for that (are we back to Situation 3 at that point?) This depends if you held any explicit ref count to the container, if you did not, it will automatically free itself and it's children when you remove it from it's parent. With those 4 situations, is the following the correct way to clean up any of the objects that I am responsible for? g_object_ref_sink(G_OBJECT(widget)); gtk_widget_destroy(widget); g_object_unref(G_OBJECT(widget)); This should work consistently yes. Widgets are GInitiallyUnowned, so their ownership is consumed by their parent widget when they are added to a parent. The exception to the rule is GtkWindow and it's derived classes, which is owned by GTK+'s toplevel window list, regardless of whether the window was ever shown or not, or shown and then hidden. Cheers, -Tristan ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GtkWidgets, Who owns what?
On Mon, 2014-11-17 at 10:02 -0600, The Devils Jester wrote: I'm sorry, Form is (I believe) a holdover term from using Visual Basic over a decade ago. I do mean Window when I say that. Most of those answers are what I expected except I am not sure what GTK considers as holding a reference. From my understanding when a widget is created it initially has a reference count of 1. No, that's indicative that you have indeed not read the documentation of GInitiallyUnowned. As I mentioned in the previous mail, GtkWidget is GInitiallyUnowned, which means it is initially created with no hard reference, and only a floating reference. Best, -Tristan If you add it to a container, the container sinks that reference (so it's now at 0). When the container is destroyed it calls destroy on its children (which deletes them if the reference count is zero). If I float the reference count manually, then the widget (and it's children if it's a container) won't be destroyed. When you say holding a reference, do you mean something that has manually increased the reference count? On Nov 17, 2014 9:33 AM, Tristan Van Berkom tris...@upstairslabs.com wrote: On Mon, 2014-11-17 at 09:01 -0600, The Devils Jester wrote: I have some questions about various situations and whether or not GTK or my program is responsible for freeing the objects/memory in these situations. Situation 1: I have a (visible) form, with a container, with a widget. I close the form. Are all the widgets (and the form) cleaned up? Normally yes, this of course depends on if you are just 'hiding' the window (afaik there is no such thing as a 'form'), or destroying the window. Also depends on whether you have any explicit refs to any of the children. Situation 2: I have the same as above, but the window is never shown, so is never closed. However, gtk_main_quit() is called. Am I responsible for the cleanup of the window? (And if I destroy the window manually, will it clean up all of its children?) Yes you are responsible for destroying the window, and yes, normally it will clean up all children. Situation 3: I have a container, that has children, but that container is never added to a form. Am I responsible for cleaning up the container? And, as above, if I destroy the container, will it clean up its children, or am I responsible for that? Yes, you are responsible for g_object_ref_sink()ing, destroying that container and then unreffing it, this is an abnormal case, and yes it will clean up it's children. Situation 4: I have a container with children (as in Situation 3), but it was added to a form at one point (and later removed). Am I responsible for that (are we back to Situation 3 at that point?) This depends if you held any explicit ref count to the container, if you did not, it will automatically free itself and it's children when you remove it from it's parent. With those 4 situations, is the following the correct way to clean up any of the objects that I am responsible for? g_object_ref_sink(G_OBJECT(widget)); gtk_widget_destroy(widget); g_object_unref(G_OBJECT(widget)); This should work consistently yes. Widgets are GInitiallyUnowned, so their ownership is consumed by their parent widget when they are added to a parent. The exception to the rule is GtkWindow and it's derived classes, which is owned by GTK+'s toplevel window list, regardless of whether the window was ever shown or not, or shown and then hidden. Cheers, -Tristan ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GtkWidgets, Who owns what?
On Tue, 2014-11-18 at 01:05 +0900, Tristan Van Berkom wrote: On Mon, 2014-11-17 at 10:02 -0600, The Devils Jester wrote: I'm sorry, Form is (I believe) a holdover term from using Visual Basic over a decade ago. I do mean Window when I say that. Most of those answers are what I expected except I am not sure what GTK considers as holding a reference. From my understanding when a widget is created it initially has a reference count of 1. No, that's indicative that you have indeed not read the documentation of GInitiallyUnowned. As I mentioned in the previous mail, GtkWidget is GInitiallyUnowned, which means it is initially created with no hard reference, and only a floating reference. Best, -Tristan If you add it to a container, the container sinks that reference (so it's now at 0). When the container is destroyed it calls destroy on its children (which deletes them if the reference count is zero). If I float the reference count manually, then the widget (and it's children if it's a container) won't be destroyed. As an additional note, this is also a misconception of gtk_widget_destroy(). gtk_widget_destroy() actually has no effect on the reference count, it emits a signal which must be trapped by any code segment which holds a strong reference to the said widget (this is the contract of any object which holds a reference to a GtkWidget, it must unref at destroy time). A GtkContainer holds a strong reference to all of it's children, so when a child is destroyed, it is automatically removed from the container (that's the container's responsibility) - removing the child from the container in turn, releases the container's strong reference to that child. The destroy signal also results in destroy being emitted on all of the destroyed container's children. Note that any GObject cannot exist with a ref count of 0, an object is disposed and finalized when it's ref count reaches 0. Cheers, -Tristan When you say holding a reference, do you mean something that has manually increased the reference count? On Nov 17, 2014 9:33 AM, Tristan Van Berkom tris...@upstairslabs.com wrote: On Mon, 2014-11-17 at 09:01 -0600, The Devils Jester wrote: I have some questions about various situations and whether or not GTK or my program is responsible for freeing the objects/memory in these situations. Situation 1: I have a (visible) form, with a container, with a widget. I close the form. Are all the widgets (and the form) cleaned up? Normally yes, this of course depends on if you are just 'hiding' the window (afaik there is no such thing as a 'form'), or destroying the window. Also depends on whether you have any explicit refs to any of the children. Situation 2: I have the same as above, but the window is never shown, so is never closed. However, gtk_main_quit() is called. Am I responsible for the cleanup of the window? (And if I destroy the window manually, will it clean up all of its children?) Yes you are responsible for destroying the window, and yes, normally it will clean up all children. Situation 3: I have a container, that has children, but that container is never added to a form. Am I responsible for cleaning up the container? And, as above, if I destroy the container, will it clean up its children, or am I responsible for that? Yes, you are responsible for g_object_ref_sink()ing, destroying that container and then unreffing it, this is an abnormal case, and yes it will clean up it's children. Situation 4: I have a container with children (as in Situation 3), but it was added to a form at one point (and later removed). Am I responsible for that (are we back to Situation 3 at that point?) This depends if you held any explicit ref count to the container, if you did not, it will automatically free itself and it's children when you remove it from it's parent. With those 4 situations, is the following the correct way to clean up any of the objects that I am responsible for? g_object_ref_sink(G_OBJECT(widget)); gtk_widget_destroy(widget); g_object_unref(G_OBJECT(widget)); This should work consistently yes. Widgets are GInitiallyUnowned, so their ownership is consumed by their parent widget when they are added to a parent. The exception to the rule is GtkWindow and it's derived classes, which is owned by GTK+'s toplevel window list, regardless of whether the window was ever shown or not, or shown and then hidden. Cheers, -Tristan ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list ___ gtk-app-devel-list
