On Jan 15, 2007, at 5:44 PM, tim Rowledge wrote:

> host windows. John did some hacks to map Squeak projects to windows  
> as a proof of concept but I don't think that is the way to go.

Well actually it was to map tweak projects to a window because a  
tweak world has a display surface and an event queue. So when the VM  
flows the events
we dispatch the event to the proper tweak world event queue based on  
which host window the weak world thinks it is managing and possibly  
alter the coordinates.
  And when the tweak world draws to the tweak surface we ensure it  
draws to the proper host window surface.

Normally the tweak project's event queue would just be filled with  
events based on focus, and the surface used would be Display.

Worked quite nicely, not a HACK....

What was a hack was the Morphic project integration I did. On a  
morphic project switch I would switch out what the Display was, and  
of course on
window activation ensure the correct Morphic project was switched to  
and the events for the proper window would flow. Because the logic in  
2004, perhaps today, assumes only one morphic project was running  
that was reasonable.

In all of this, if one looks at the SUnit you'll see how to interact  
with a window and draw to it without any regard to what Morphic thinks.

Sadly looking for Sensor and or Display usage will cause one's blood  
to run thin... The fun part is that in *lots* of usage there is no  
context to decide which
drawing surface we are dealing with...

--
======================================================================== 
===
John M. McIntosh <johnmci at smalltalkconsulting.com>
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
======================================================================== 
===