Lex,

> Thanks for the additional thoughts.  Maybe aiming a little lower would
> be helpful?  The needs of a graphics toolkit like GTK are used in
> limited ways. 

This is true. I have also pointed out at various times that the lack of
callbacks is no reason not to interface (for example) Win32 or X11. Most
UI toolkits support a polling interface for events which can be put to
good use here. I'd be surprised if GTK wouldn't.

> If one only supports enough to talk to GTK:
> 
> 	1. You don't need to generate your own C functions to deal with
> callbacks -- you can write the redirectors as C functions in 
> the plugin.

This may or may not be enough (I don't know the specifics about GTK
here). You will have to deal with the problem of "instantiating"
callbacks, if for example, they need to be provided on a per-window
basis (which is usually the case). In this case you need to provide an
arbitrary number of callbacks (depending on the number of windows you
have) and unless you don't want to arbitrarily limit the number of
available callbacks (and therefore windows) you will have to do
something to instantiate the callback.

> 	2. The threading is simplified.  The main Squeak thread 
> will be blocked by a call to a primitive that calls some sort
> of gtk_mainloop() function.

If you can provide "static callbacks" (e.g., by using redirectors) then
this is no issue at all because the redirectors can handle this stuff.
If not, then it might be more problematic. If GTK does not use a polling
interface (if it does, you can trivially implement the polling through
FFI) then it probably does so for a reason. So you have to be aware that
a call to processEvents() may invoke a callback (processEvents is called
from checkForInterrupts() at some unlikely places so careful here).

> Thus the thread that handles callbacks will not be
> interrupting the main thread at a weird location, and it will also be
> safe from being starved by the main thread.

Without knowing the specifics of GTK these are shaky assumptions. See
above. The best thing you can do is to look at the source code of
gtk_mainloop and see what it does. If it's doing what I'd expect it to
do (namely poll for and dispatch an event) then you can just implement
this directly in Squeak ;-)

> Also, nested callbacks won't happen so long as you are using 
> just *one* of these libraries, and it is set up like GTK.

Are you totally certain about this? Nested events (and therefore
possibly callbacks) are quite common for your average Windows app.

> It would be very nice to do it all using FFI straight in the image and
> not write a line of C code.  But requiring juts a bit of glue 
> code to be written can simplify things to something managable,
> it seems.

Again, look if GTK supports a polling interface. If so, there's no
reason for using a single callback.

Cheers,
  - Andreas