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@smalltalkconsulting.com 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== ===