> Perhaps the trickiest
> part (to my mind) would be deciding how to handle input events; one
> global queue, one per host window? What about other sorts of events that
> aren't really window tied?

I don't see why there should be any significant differences to the way it is 
handled now.  Think of the two OS-top-level windows as two top-level windows on
the Squeak desktop; they simply happen to be presented in a somewhat oddball
way.

In fact, it may well be possible to implement this with only very minor
changes to Squeak.  Let's say we assign each OS-top-level window to a virtual
rectangle in Squeak's coordinate space.  So, the default OS-top-level window
has its top left coordinate at (0,0), the next top-level window has its 
top-left corner at (10000,0), the next one at (0,10000), the next one
at (10000,10000), etc. (these virtual coordinates would, of course, be user
specifiable).

The OS interface clips drawing requests to each top-level window, and it
also translates OS-window-coordinates into Squeak-global-coordinates for
incoming events.  These changes would be almost exclusively confined to
the OS (X11, SDL, Win32, Carbon, Cocoa) interfaces, and they could take
advantage of the native clipping and coordinate translations in each
window system.  Then, there would be a handfull of additional native
calls to actually create and destroy global windows.  Overall, I think
the amount of native code needed to do that would be tiny, both compared
to the code that is already there and compared to the code that would
need to be written for any other scheme.

Even things like dragging across OS-windows and moving morphs between
windows would work with no changes to existing code, since from Squeak's
point of view, they are just manipulations on a single, large desktop.  
Event handling would also be unaffected, since morphs contained in 
different top-level windows would behave the same way as morphs that 
are side-by-side on the same Squeak desktop.

OS-windows would still be separate entities that might come with a few
extra methods for moving them around on the OS-desktop.  There should also
be a few OS-desktop-related methods for handling external cut-and-paste
and external drag-and-drop.

I don't know whether one should view such an approach as "elegant" or
"kludgy", but it looks to me like it would provide the greatest degree
of backwards compatibility while letting Squeak developers write fully
functional multi-window applications using Morphic.

Tom.


__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com