(I see you created a separate thread for this at the same time I
responded in the Meeting Notes thread, so I pasted my take from that
thread below, for continuity in this thread, sorry!)

New users' first experience upon launching Squeak should be an
immediate commencement of their journey to discovery and wonderment,
not a tedious and meaningless (to them) message that tasks
them with some chore they couldn't possibly care about at that point.
Many would bail right then and there.  Personally, I think most users
that would use a system like this would know about files and folders
and would simply re-unzip it, but if you feel strongly the system
should hold their hand then lets actually hold it by handling it for
the user *automatically*.   A tweak to the launcher scripts included
in the All-In-One.  Simply change the script to make a copy of the
"master" and then launch the copy.  If  the copy already exists (i.e.,
from last time), launch it instead of copying it over.  Then, we
simply include a "factory-reset" script which deletes the copy.  Done.


On Thu, May 17, 2018 at 4:20 PM, tim Rowledge <tim at rowledge.org> wrote:
> I've long tried to argue that the release images ought to start up in state where they insist on being saved under a new, user chosen name as the first (or nearly) action. This way the release image (and changes) could be locked, guaranteeing that there is a clean image on-disk for the inevitable "Dang!" moment. This seems to me to apply doubly for the all-in-one systems since those release images are buried so deep in directories that you have to look up to see the Mohorovičić discontinuity far above you.
>
> What I claim ought to happen is that the current and very excellent preferences wizard should be extended to open a file saver dialog and insist on the image being saved. We would need to do some directory path parsing to make sure that we actually offer a realistic directory and not the /Users/tim/Documents/Squeak/Squeak-5.0-All-in-One.app/Contents/Resources/Squeak5.0-15113.image path I see on my iMac; I'd posit that find the all-in-one part and chopping just before it might be adequate.
>
> I can see one situation where this might cause a problem that needs some thought; when using a script to prepare an image eg the VMMaker build scripts. I see the 'NukePreferenceWizardMorph.st' in the vmmaker build scripts which removed the pref wizard ok, but it still leaves the image being saved over the original. Strictly speaking this is very unlikely to be a serious issue with the vmmaker regime because we almost always load the images into the mv/image working directory, but it's a poor example to have around. Changing to make the 'NukePreferenceWizardMorph.st' save the image under the new name and then dropping the copy in buildspurtrunkvmmakerimage.sh might be nicer?
>
> Next question is whether anyone can think of serious problems with making this change?  And then, how to implement it cleanly?  I *think* it might work to over-ride #delete in PreferenceWizardMorph which is sent when the chance to configure is declined right up-front, or when the user clicks on 'Done'.
>
>
> tim
> --
> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
> Strange OpCodes: CAO: Compare Apples to Oranges
>
>
>