Re: tooltips and refcounts

[Tim Janik <timj gtk org>]

On 2 Sep 1998, Owen Taylor wrote:

> 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. 

as i stated in an even older mail on this subject, the *actuall* ref count
is not of the application writers bussiness. whether its the widgets tooltip
or GLE or an interpreter or some gtk internal code, e.g. a long lasting
timeout, who's holding a pending refcount on an object is really of no
interest to an application. that's because ref_counts only care about the
widget's memory allocation and should have nothing to do with their
actuall on-screen appearance. that's why containers destroy widgets
explicitely upon their destruction and don't just decrement a refcount.

> 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.

this assumption is false, refcounting.txt describes this in a detailed
manner, refcounting cares about the finalization stage of an object, it
just happens that this implies the explicit destruction as well, which
is why a not yet destroyed object gets destroyed when the last refcount
drops.
if you want a widget to "go away", i.e. take visual action on screen,
you have to gtk_widget_destroy() it.

> 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".

you are right that the tooltip's ref count on widgets is redundant, but
even though it may short-time-cure the panels problems, that's just fighting
symptoms. if the panel relies on certain refcounts, that behaviour is
_conceptually_ wrong. maybe its currently just the tooltips that cause
this assumption to fail, but you can soon encounter different problems
wrt refcounting with such behaviour, e.g. if you use GLE or if we someday
decide to implement some kind of global GC for gtk.

> > > 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.

this is actually the case for toplevels, you can sink() and ref()+unref()
on a gtkwindow anyway you want, it won't get destroyed untill you explicitely
state so. most other objects actually get destroyed on their initial sink()
call if not ref()ed before, but that's just because destruction is an implicit
requirement for finalization, which is what refcounts are really about.

so the baseline is, if you want a widget to disappear: destroy it, unparentation
will immediatedly be taken care off, memory deallocation is handled at
finalization stage which might get delayd for reasons not apparent to the
application/programmer.


> 
> Regards,
>                                         Owen

---
ciaoTJ