WxSqueak 0.4rc First Impressions

[Steven Swerling]

Hey Rob,

I just built WxSqueak on MSW using MSVC. It built after one small tweak 
-- I had to exlude the B3DAccelerator Plugin. I'm probably missing some 
support library for this and didn't want to fuss around with it. I'll 
post a little write up for people that wish to do same.

I haven't found any bugs using the demo, which looks and works great. No 
crashes so far. A lot of classes appear to have been cleaned up. Bravo.

A Request: Use Monticello. You would have to move all of your changes to 
the base system into a method protocal called *wx. It also would be nice 
to have a SAR install file that contains the monticello package along 
with the WxConstantMap file so that loading WX is a one click affair. If 
you'd like, I'd be happy to do these things for you. Using monticello 
will make it a lot easier for others to keep up with your changes, and 
easier to port WX to other versions of Squeak (I'm thinking Spoon here. 
Craig has said he'll either get a 3.7 Spoon going or backport some of 
the key tools like monticello). You will also find it's a lot easier to 
manage a monticello package then it is to manage a changeset.

FYI, I filed the WxSqueak changeset into my QuiteSmall image. (It works 
fine.) The difference in the image size was about 4.6mb after the filein 
(after deleting the changeset). Removing the Demo and Sample classes 
shaved off about 350k, leaving no obsolete references. QuiteSmall is 
about 3.6mb, and I estimate that the formal packagizing projects won't 
be able to shave much off of that without going into the base classes 
(Collection-*, Kernel-*, etc). Let's just guess they get about 0.5 mb 
improvement over QuiteSmall. So for now, we can guess that down the road 
a "core" wxSqueak image will be in the neighborhood of about 8mb.

[Request2: (Rob, I've made this request off list before but want to get 
it on the list just for the record).

Give the option of deferred event processing, an analog to 
WorldState>>addDeferred. In many cases methods won't need to be fired 
synchronously. Why risk callback trouble resulting from bugs in those 
methods?

It can be as simple as 1-2-3:
1. Add EvtHandler>>#on:id:lastId:send:to:defer:, just like 
#on:id:lastId:send:to, but it would take a boolean for defer. At the 
line where you have "(self handlerFor: eventSymbol) at: anId put: (Array 
with: anObject with: selector)", just add the "deferred" boolean as a 
3rd element of the array.
2. Add a method called "on:id:deferSend:" to go along with the sync 
"on:id:send". "on:id:send:" would call #on:id...defer: with the value of 
"false" for the value of defer, and the #on:...deferSend: method would 
call it with true.
3. When handling the event (the #handleEvent: method), check the 
deferred bit -- if it's deferred, rather than call the method, put it in 
a SharedQueue that works just like the one in WorldState.
]

Regards, Steve S.