>I'm sure this has been addressed many times, but there is no good source
>of documentation at the swiki. With the changes in 2.8 and 2.9a things
>have probably changed enough that this question is worth revisiting in
>the context of the 'ship it with squeak' discussion.
>
>I would love to be able to ship a squeak image that had only morphic,
>the necessary programming classes and the classes necessary for my
>application. Is there a semi-magical method? Failing that, how do I go
>about doing this systematically (that is without simply wiping out
>classes sequentially and checking to see what fails.) Finally, compared
>to the base image (say 2.8) - what are reasonable expectations for a
>reduced image size (with morphic, without MVC (is this possible?), with
>the network support, Scamper, Celeste, the morphic widgets and toolkit
>classes but without the 3D stuff, Wonderland, speech, music and all
>those nifty toys etc.)

Michael -

This has to be readressed every few versions and, at this point, the various inclusions and exclusions are not reliably modular.  It's not hard to get down around 700k with development system but without sound, network or Morphic.  With Morphic (less scripting), tools, Network and the two apps you mention, my guess is you'll come in around 1.8-2Mb plus or minus depending on whether you want sound and, if so, how much.

You should certainly try the various discardX methods and at least read majorShrink in SystemDictionary.  As you point out, we need more documentation about this.

I once started on a web page that would describe everything in the image (ie what you need to know besides all the classes and their methods), how to search for various subtle things and, finally, how to successfully shrink an image.  If anyone else wants to tackle this job with me as a tutor, it might happen sooner, judging from my current to-do list.

I think Stefan Aust recently got pretty deeply into this, and I think Jerry Archibald has also.

People will tell you this is the problem with the unified image approach, but I disagree.  The problem is simply that we haven't drawn appropriate lines between the various parts of the system, so when you cut one out, you're left with dangling dependences.  I think that real value would come from declaring this as a project, with a goal of having maybe 20 discardX methods that really worked and that wouldn't get out of date in the next month.  This project would also overlap with or feed into the Environments project.  That one's actually on my to-do list, so maybe this is a good way to go at it.

	- Dan

PS it's also related to the problem of what to do about error dialogs in a headless system (a headless system is just one in which you have run the discardGraphics method ;-).