WxSqueak 0.4rc First Impressions

[Rob Gayvert]

Steven Swerling wrote:

> 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've seen problems with this plugin before, but I'm not sure what's 
special about it.

> 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.

Good idea. I should start using Monticello, so I'll give it a try. It 
doesn't look hard, so I'll shoot for a SAR file for the general 0.4 release.

> 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.

Not a bad size, and I think we could get even smaller by taking out some 
of the wx code: the code generation and deprecated categories aren't 
really necessary, and there are quite a few redundant wrapper methods 
that I need to eliminate.

> [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.
> ]

Sorry I dropped the ball on this one. It was definitely on my list for 
0.4, so let's try to get it in right now. I think I've got your scheme 
working; I  just need to test it a bit.

The whole #on:id:send:to: family of methods needs to be reviewed. I 
threw in convenience methods like #onMenu:send: as I implemented the 
demos and found that I couldn't remember if it's supposed to be 
#wxEvtCommandMenuSelected or #wxEvtMenu or whatever. As a result, the 
current methods are a real hodgepodge. The C++ and wxPython bindings use 
a bunch of macros like EVT_MENU to simplify matters. We need a scheme 
that is consistent with these macros but a better fit for Smalltalk.

.. Rob