Ffenestri (multiple host window support), and Mac Host Menus
John M McIntosh
johnmci at smalltalkconsulting.com
Tue Jan 16 02:16:16 UTC 2007
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
More information about the Squeak-dev