On loading WxSqueak into a fresh 3.7

[Steven Swerling]

Hi,

I played around with trying to get Wx's mcz to load into a fresh squeak 
3.7, trying various strategies. Not that it's not doable, but it's 
awfully slow going. Monticello seems to have a very hard time with Wx, 
so the turnaround on each experiment or change is very long (about 1/2 
hour on my machine).

MCZ files are still a good way to get new changes from Rob on an already 
working system. The trouble with a fresh image is getting all those 
constants initialized at the right time, and Monticello is not able to 
be flexible when it comes to classes with pool dicts.

Perhaps some interim steps are in order (but imminently deferrable). Try 
to make 4 separate Wx monticello packages:
- A package for all the base system extentions, called, say, 
*wxextentions. Easy.
- A package for the plugin generation. This stuff has a dependency on 
VMMaker, itself a rather large package, so it might be nice to separate 
out from Wx proper. Probably pretty easy.
- A WxBootstrap package that just contains those few classes needed to 
get filed in so that all the constants can be initialized. It's 
necessary to initialize all the constants before all the subclasses that 
access those constants get filed in. This is complicated by the fact 
that some of the WxConstants are objects from the Wx sub hierarchy (like 
a WxColour for wxBlack). Very hard.
- WxWidgets -- the rest of the classes. Easy.

That's a lot, enough that I can see how you might want to just skip it, 
say they have to get it all working "by hand" in a fresh image, and just 
use monticello for updates.

Anywho, I underestimated how hard it would be to generate a SAR file. I 
didn't realize how hard it would be to handle all those constants 
sitting in the Pool dictionary.