Well yes I could attempt to handle it in the VM, but that's quite a  
bit of C code that has minimal folks supporting, and in case of
bugs few folks that would fix it, plus of course the upgrade path  
isn't automatic, one must download a new VM from somewhere.

  If everything is in the image then fixing it becomes a bit easier,  
plus you then can handle the case of what you want it to do, open a  
new application, start the simulated interpreter, look
at the bytes? On the other hand perhaps I'll put some C code together  
just to understand the complexity.


On 12-Sep-05, at 3:48 PM, Andreas Raab wrote:

> John M McIntosh wrote:
>
>> Well the problem is that when you double click on an image in the   
>> finder, *IT* looks in it's magic table of file types or file  
>> suffixes  and say's mmm that Squeak application over there
>> says it handles files of type Squeak or suffixes of .image and  
>> look  one is running already, so let's do an Apple Event open  
>> document  request to it. This incorrectly assumes of course you  
>> run one copy of  your application which handles multiple open  
>> documents.
>>
>
> But that would be okay if, say, the VM handled the open document  
> event and spawns a new VM with the image in question, no? It might  
> be somewhat confusing if you actually drop an image onto another  
> running Squeak and expect it to be handled inside Squeak itself but  
> my guess is that most people would prefer this to the current  
> situation and it could also be controlled via some (VM-level)  
> preference.
>
> Cheers,
>   - Andreas
>
>
>

--
======================================================================== 
===
John M. McIntosh <johnmci at smalltalkconsulting.com> 1-800-477-2659
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
======================================================================== 
===