Re: Building STk on HP-UX

From: Tom Lord <lord_at_cygnus.com>
Date: Tue, 14 Feb 1995 11:56:26 -0800

Hi.

I was thinking about hacking libtk to add callbacks to the functions
that parse widget configurations (off the top of my head i think the
key one is called something like Tk_ConfigureWidget).

The callbacks would work this way. Every widget would have a list of
callbacks that can be set from C. Whenever a configuration option
is modified by one of the helper functions, the callback functions
are called. Callbacks would also be called when the widget is destroyed.

That way, just as kanderso suggests, real closures could be automagicly
assigned string names and used as "-command" options. When those
closures were overwritten or when the containing widget goes away,
the callback can be used to make sure they are properly GC'ed.

This change to libtk can be made in an upward compatible way and is useful
even just from C.

-t

   Resent-Date: Tue, 14 Feb 1995 06:22:07 -0800
   Resent-Message-Id: <199502141422.GAA00946_at_cygnus.com>
   Cc: Berry Kercheval <kerch_at_parc.xerox.com>, stk_at_kaolin.unice.fr
   Date: Tue, 14 Feb 95 09:00:08 -0500
   From: kanderso_at_BBN.COM
   Resent-From: stk_at_kaolin.unice.fr
   X-Mailing-List: <stk_at_kaolin.unice.fr> archive/latest/396
   X-Loop: stk_at_kaolin.unice.fr
   Precedence: list
   Resent-Sender: stk-request_at_kaolin.unice.fr

   Does this approach make sense?


   (button "Frob" :command
      (create-callback table (lambda () (frob ...))))

   Create-callback interns the closure and associates it with a string. It
   returns a string that when executed by Tk looks up the calback by name and
   funcalls it. If you had one table per application, you could throw it away
   when the application is deactivated.
Received on Tue Feb 14 1995 - 20:59:09 CET