RFC: Reference counts on Gtk2::Tooltips



it's not a bug, it's feature.  no, really!

short version:
--------------
   should $tooltips->set_tip ($widget, ...) save a reference to $tooltips
   in $widget, or simply document the fact that you have to save the
   $tooltips object or the tooltips don't show up?


long version:
-------------

this code:

  sub make_a_thing {
     my $tooltips = Gtk2::Tooltips->new;
     my $button = Gtk2::Button->new ('hi there');
     $tooltips->set_tip ($button, 'this is a test', 'this tooltip will not be
seen because we're not saving a reference to the tooltips object');
     return $button;
  }
...
  $thing = &make_a_thing;
  $window->add ($thing);
  $window->show_all;
  Gtk2->main;


creates a window, and properly sets up the tooltips, but the tooltips do not
show.  why not?  because at the end of &make_a_thing, the lexical $tooltips
goes out of scope and disappears because there are no references to it (other
than the wrapper's ref), before the window gets shown.


this happens because although the tooltips object stores a pointer to itself
in the client widget's user data, it does not allow that pointer to keep a
reference.  thus, it is up to the application programmer to store a reference
to the tooltips object which will outlive the objects which have the tooltips
attached to them.

in other words, it behaves as designed.


however, that behavior is rather surprising.  also, from what i can tell it is
unexpected, since most C code i've seen actually leaks the tooltips objects so
they stay alive by accident.

it is trivial to have the perl wrapper for set_tip keep a reference on the
tooltips object so that it will stay alive; my question is, since it's
behaving as designed, is this subversion the right thing to do?  or should we
simply document the behavior in a "pitfalls" or "gotchas" document?


-- 
muppet <scott at asofyet dot org>





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]