Re: [gtk-list] Reference counting (fwd)

[Tim Janik <Tim Janik Hamburg Netsurf DE>]

On 22 Nov 1997, Marius Vollmer wrote:

> All widgets that are part of the display are linked into a
> parent/child tree.  The link from the parent to a child is reflected
> in the ref_count of the child, but the link from the child to the
> parent is not reflected in the ref_count of the parent.

what exactly happens to widgets that don't fit into the simple
widget tree linkage?

e.g.
void       gtk_menu_item_set_submenu      (GtkMenuItem         *menu_item,
                                           GtkWidget           *submenu);
void       gtk_option_menu_set_menu    (GtkOptionMenu *option_menu,
                                        GtkWidget     *menu);

or (if that is to come)
void       gtk_tree_item_set_subtree    (GtkTreeItem *tree_item,
                                         GtkWidget   *subtree);
how is the reference counting handled in this cases?



and
void         gtk_tooltips_set_tips   (GtkTooltips *tooltips,
                                      GtkWidget   *widget,
                                      const gchar *tips_text);
this doesn't do ref-counting on either side, will it stay this way?

also there is one assumption you make that i don't like.
GtkWidget::destroy isn't only used for freeing memory on the
application side. some applications (e.g. GUBI) use this signal
(which is asured to be invoked by a gtk_widget_destroy() call,
if all referencing went right)
to clear internal references/pointers to this widget.
e.g. if GUBI creates a button, it stores the widget pointer
at a special location, let's say

GtkWidget *button1;
button1 = gtk_button_new_with_label ("huhu");

then it connects a handler to the GtkWidget::destroy signal of
the button that will do a button1 = NULL;

now if some widget specific parameters are changed that require
this button to be rebuild, GUBI will do a gtk_widget_destroy (button1);
and then expect button1 to be NULL (this is required because button1
will now be used again for the recreation)!

> The action that is currently performed by gtk_widget_destroy is
> therefore identical to gtk_widget_unparent.  Both basically mean "take
> this widget off the screen".  This does not directly and invariably
> cause the widget to be freed and having its finalization code run.  It
> only happens when the former parent was the last reference to the
> widget.

in my above example gtk_widget_destroy() isn't only used as "just get off
the screen, and at will free all associated memory" but also
as "... give free all resources you might allocate on the application
side" which is, technically speaking, the invokation of the destroy handlers.

i'm not too sure how this behaviour would be preserved in the new reference
counting scheme...
may be this could be done by another signal emission GtkWidget:unparent
on gtk_widget_unparent(). but then again this would be executed on other
calls like gtk_widget_reparent()...


> Toplevel widgets, which don't have a `natural' parent, are adopted by
> a special widget, maybe a GtkDisplay or GtkScreen.  This special
> parent of all toplevel widgets is never freed.  The toplevel widgets
> are added to this parent as soon as they are created.

ugh, there is lots of code that identifies toplevel widgets by their
parent pointer being NULL, that shouldn't be changed.
also it's not natural for a TOPlevel widget to be unparented. the fact
that it realy is a child of the root window, is more of a technical
issue than a gtk gui programmer should care about...
IMHO, at least toplevel widgets should be destroyed explicitly
(e.g. by gtk_window_destroy() if gtk_widget_destroy() goes away),
because the destroyment of a toplevel window is something the programmer
already has to explicitly take care about, let that be by a "Quit" button
or a connection to GtkWidget::delete or a certain state (e.g. a progress bar
has reached 100%) or what else.


---
ciaoTJ