On 17 Apr 2004, at 23:59, John M McIntosh wrote:

>
> On Apr 17, 2004, at 1:33 PM, Andreas Raab wrote:
>
>>> A Dire Warning - once you start on this path, be ready for demands 
>>> for
>>> host OS widgets, fonts, menus, callbacks, transparent OS handles (and
>>> the problems of portability will make you tear your remaining hair 
>>> out)
>
> Well the historical mac vm code assumes you've only one window, so 
> some cleanup is required
> to fix that issue. I looked into a few years back when I was 
> considering an About window. Problem was
> the changes needed were more than a few hours of work (sigh). Also 
> subtle things come into play, like
> going to full screen, let alone this tendency to refer to the stWindow 
> global variable directly, versus fetching
> the window to draw in, or the window which should processing the UI 
> events.

The CocoaSqueak VM makes no such assumptions.  In fact, it doesn't even 
assume there is only one VM running.  It uses an Objective-C object to 
represent a Squeak VM, and a View for Squeak output (not even a 
window), so you can place it anywhere you want within an application 
using IB.

The VM object uses various delegate objects for output, including sound 
and screen output.  So if you want to run headless, just instantiate a 
VM without giving it a screen...

Of course, Squeak itself doesn't currently allow that flexibility to be 
used, due to the use of global variables in the VM (John's path would 
largely fix that) and assumptions of a single Display in both the VM 
and the image.

I also tried to get stuff out via the Surface plugin once, but got 
stuck in lots of twisty little passages, all looking the same and all 
looking not quite like the thing I would have needed.

Anyway, the view that is reflected in the choices I made is that if 
everything is an object, then Squeak itself should also be an object, 
composable, embeddable, callable.

Marcel