This class provides a set of handful features that you can choose to reuse in your applications:
- Reference counting: an object is not deleted while there exists at least one reference to it. Although GtkAda mostly takes care of that aspect transparently, you might need in some obscure cases to increment or decrement the reference counting for a widget manually, so that it is not removed from memory while you still need it.
- User data: any number of data can be attached to a Gtk_Object or one of its children. Theses data are referenced by a String, in a hash-table. GtkAda itself uses this feature to provide an easy conversion between C and Ada widgets. Although you might prefer to have a completely object-oriented application (and thus associate data through class inheritance), it might be convenient to directly attach some data to your objects.
- It also contains the basic structures and subprograms required for signal emission. This is of course used to implement the signal mechanism in GtkAda itself, but can also be used to implement a Model/View/Controller framework.
Note that a lot of functions provided in the C interface are not provided here. They are used to emulate an object-oriented language in C, which can of course be done much more conveniently in Ada. Therefore most of these functions are not needed.
Here is a brief explanation on how the reference counting and destruction process work. You should not have to understand all this to use GtkAda, but it might help anyway.
When an object (descendant of Gtk.Object) is created, it has initially a ref_count of 1. A flag is set to say the object is "floating". See the Flags functions in this package for how to retrieve the status of this flag.
When the object gets a parent (ie Gtk.Widget.Set_Parent is called, possibly from other subprograms like Gtk.Container.Add, Gtk.Box.Pack_Start, ...), the ref_count of the object is incremented to 2. If the object was still "floating", it is also "sinked", ie its ref_count is decremented to 1, and the "floating" flag is cleared.
The same behavior as above happens when the object is registered as a top-level widget (i.e. we know it won't have any parent).
Thus the normal life cycle of an object is to have a ref_count to 1, and not be a "floating" object.
When the object is destroyed, the following happens: A temporary reference to the object is created (call to Ref), and ref_count to 2. The object is shutdown: It is removed from its parent (if any), and its ref_count is decremented to 1. The "destroy" signal is emitted, the user's handlers are called, and then all the handlers connected to the object are destroyed. The object is unref-ed. If its ref_count goes down to 0 (normal case), the memory used by the object and its user_data is freed.
When a widget is destroyed, it will break any references it holds to other objects. If the widget is inside a container, the widget will be removed from the container. If the widget is a toplevel (derived from Gtk_Window), it will be removed from the list of toplevels, and the reference GTK+ holds to it will be removed. Removing widget from its container or the list of toplevels results in the widget being finalized, unless you've added additional references to the widget with Ref.
In most cases, only toplevel widgets (windows) require explicit destruction, because when you destroy a toplevel its children will be destroyed as well.