> 1) Is it possible to get morphic to create a window outside of the
> squeak window

Probably not the way you want to do it. At least, not easily. And not out of 
the box. That is: if you want multiple active Morphic windows at once, each 
displaying something different, it's going to take a bit of work (I think).

You can get *Squeak* to create such a window (via FFI or via a plugin like 
the XDisplayControlPlugin), and to *draw* things on it. However, you 
(probably) won't be able to use it (normally) with Morphic. To be able to 
use any display surface with Morphic, you need:

* a Canvas for drawing: you can change the kind of Canvas that is used by 
  the WorldState (this is how, for instance, Nebraska works; see 
  MultiCanvas).
* a HandMorph for input events: by changing the kind of Hand (or adding a 
  different kind) you can get input events from somewhere else. (again, this 
  is used in Nebraska).

It is conceivable that you could set Morphic up to allow for multiple 
worlds, each with their own rectangular display surface (each one of which 
could be connected to a separate window if you wanted), but they wouldn't be 
able to interact very well.

If all you want is to use native windows as an output surface for drawing, 
or to make native windows that are populated with native widgets, this 
wouldn't be a Morphic world. Göran Krampe and others have made connections 
between Squeak and native UI widgets.

Though you could tell a Morph to draw itself on a Canvas associated with one 
of these display surfaces, it wouldn't be 'live' in that environment unless 
there were also a corresponding Hand there. This is like how we can draw a 
Morph on (say) a Postscript canvas.

Morphic *does* assume a single, large rectangular display surface per World, 
so unless you somehow were able to stick together multiple rectangular 
window areas and make them look like a single surface, these would have to 
be in separate Worlds.

Having separate Worlds is probably not that difficult. But it's not 
supported by the stock code (directly). Specifically, we don't have the 
kinds of Hand/Canvas combinations you probably would need.

I don't know that it would be all that hard to have a multi-surface World 
either, but you'd have to manage to merge the UI event stream for each of 
the UI-level windows together (supplying appropriate coordinate 
transformation), and probably have a special damage recorder that also knows 
about the separate areas.

There would also be the challenge of mapping OS-level/window system 
coordinates to Squeak coordinates, especially if you can move, resize, or 
overlap the individual windows.

Right now, the VMs (at least the Unix and Win32 VMs) have a single global 
called something like 'stWindow' that maintains their idea of the single 
active Squeak window (more or less). They would have to be extended to allow 
the use of multiple windows.

> From what I can tell, Squeak is far from having even prototype native
> widget support; obviously, there are hacks using FFI as was mentioned

Well, wxSqueak looked pretty functional to me. It has a pretty impressive 
demo.

http://homepage.mac.com/rgayvert/wxsqueak.html
------
You can do exactly the same thing with Squeak:

* rename Squeak.exe as your-app.exe
* rename the image to your-app.image
* run your-app.exe (it will automatically load your-app.image)
* turn off the prefs for warning on sources and changes files
* do an abandonSources
* save the image
* throw away the .sources and .changes files

> Lastly, the image stripping facilities are pretty impressive, even
> going as far as replacing walkbacks with dialog errors, thus shielding
> any problems from the user without confusing him terribly. In other
> words, some of the traditional 'evils' of stripping an image are
> lessened, and locked down distribution is improved.

My Lockdown package helps quite a bit with this process, though it doesn't 
do any stripping.