Re: tooltips and refcounts

[Owen Taylor <otaylor redhat com>]

[ OK, this is a very late response. I didn't figure out what
  this thread was about until I was trying to fix refcounting
  in the panel. ]

Tim Janik <timj@gtk.org> writes:

> On Mon, 10 Aug 1998, George wrote:
 
> > ok .. this is kind of weird (I think so) ...

> > adding a tooltip to a widget increases it's refcount ...  this
> > doesn't make sense to me really ... the tooltip doesn't own the
> > widget but just the opposite ... the tooltip should bind the
> > widgets destroy signal and die when the object is destroyed ...

> > I thought refcounts were an owner->slave relationship ...
 
> hm, that's not perfectly true. you increase the ref count for a widget
> if you are keeping a reference to it, which is what the tooltip does.

But, the point George is trying to make is that the application
writer does not want to know that the tooltips is keeping
around a pointer to the tooltips. 

Generally, one assumes that one drops the last refcount to a widget,
it should go away, without needing to also destroy it. Once
you've set a tooltip on a widget, this no longer works, and it
will not go away until you destroy it explicitely.

But, the root point is that there is _no need_ for the tooltips
to reference the widget - since they connect to the "destroy"
signal, if we don't ref the widget, then the behavior will
be that the tip will persist as long as the widget exists
and then go away. (If you are paranoid, you could check for
!GTK_OBJECT_DESTROYED() when setting the tip)

This is a classical "weak reference".
 
> > this tooltip thing actually makes things complicated ... in the panel for
> > example I have a lot of widgets for which I set tooltips ...
> > 
> > I have put a "set tooltip to NULL function" in the applet clean up code ...
> > however that code isn't allways called ... for example when I remove a panel
> > (a drawer) ... I rely on getting the destroy signal from the applet ...
> > which however never comes .. as when the widget is unparented it still has
> > a refcount hanging around .. and the widget will stay and eat up ram (plus
> > I can't do cleanup) .... manually going in and setting all tooltips to NULL
> > seems like a VERY UGLY solution ...
 
> you most probably don't do the right thing in your code then.
> you either just want to reparent a widget from one window to another (and
> in this case there is no reason for gtk to implicitely remove the actual tip
> you have set for this widget), or you want to destroy it, in which case the
> tip will be removed. but either way, if you want widgets to be destroyed,
> call gtk_widget_destroy (widget) on 'em, but don't unparent or remove
> a widget and then wait for its destruction.

Yet you _should_ be able to do that. One big point of the
refcounting scheme is to make things easy on interpreted languages.
The interpreted language ref's and sinks the widget upon creation.
If, when the interpreted language loses its last refcount to
the widget, the widget should be freed if it is not in the
widget heirarchy.

There is a reason why we don't just create widgets with a reference
count of 1 and decrement on destruction. But you seem to
be saying that that would be OK behavior - i.e.:

 * A widget won't be freed until someone calls gtk_widget_destroy()

Ugh.

Regards,
                                        Owen