Ffenestri (multiple host window support), and Mac Host Menus
stephane.ducasse at free.fr
Tue Jan 16 09:25:40 UTC 2007
Do you think that this is reasonable to rescue this project. Because
after reading your comment I have the impression that
I was wrong suggesting to have a look at what you did.
On 16 janv. 07, at 03:16, John M McIntosh wrote:
> 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
> 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://
More information about the Squeak-dev