"Andrew C. Greenberg" wrote:

> >Well my precise reason for writing to the news group about the topic was to
> >(a) find out if anyone else had any thoughts on the matter
> >(b) find out if anyone has done any work already that could be picked up
> >(c) find out who has any interest towards beginning a project like this?
> >(d) decide whether I can commit enough time to trying to do it.
> >
> >So, please hands up anyone that could contribute anything at all (not even
> >long
> >term, just the drop of an idea here or there)... I still have a lot of
> >reading to do
> >to get this off the ground. I can build my own Squeak primitives now and I am
> >
> >familiar with two OO GTK implementations (gxk and gtk--) but I still need
> >to see how others have done it and begin my own planning.
> >In the ST world I'm still just a baby, but I'm learning quickly (or so
> >I think) and
> >I know I'm likely to step on a few feet.
>
> Early on, I looked into implementing a Tk/Tcl interface, akin to
> Python's Tkinter.  That project was stopped primarily because of the
> inability to effectively arrange for a function callback.  No present
> approach to external primitives provides decent capabilities in this
> regard.  You may wish to consider whether this facility is necessary
> or desirable before beginning this work, or to focus your efforts at
> that issue first.

Yes, I've been thinknig about this explicitely for the past few days. I'm in the
process of delving enough into the interp.c generator and the way it all
interacts with the dynamically linked libraries.
My first thought was to do it the horrible way and have a thread running
constantly asking the C code if there has been any signal and have every signal
registered with a widget watched through this C routine.
This would give the ability to defer graphics widgets redraw and control.
The second idea I had was to allow my smalltalk code to give the C code some
anchored space in memory to poke events in a queue fashion so that I could have a
thread running which would use semaphores to watch the queue space for new events
and then all widgets would be registered through this threading class instead of
with a C function.
Both ideas are very similar to each other but with slight twists on the concept.
I'm curious to dig further and see if this is actually possible or not.
But I invision a dynamically linked C/C++ library knowing all the widget
instances and their callback signals which are registered, having it talk to
GTK and telling GTK to always call _me_  when a signal is sent, .marking it down
and storing the GtkEventConfigure and gpointer data for the Smalltalk program to
handle. Then doing the nasty ST thread to step through the queue of event
callbacks and shuffle them off to their correct destinations.

Michael Lucas-Smith