WxSqueak 0.4rc First Impressions

[Steven Swerling]

Rob Gayvert wrote:

Off topic: I like your "Presenter" architecture. Clean.

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

Any help you need, send me a note. To get you started:
  1. Open a monticello browser and hit the +Package button.
  2. Name the package WxWidgets.
Now all classes in system categories that are named WxWidgets-* will be 
part of the package, and all methods that are in other classes (outside 
the package) will also be included if there message category is named 
'*wxWidgets'.
  3. Go to every method you put in Browser, Debugger, etc., and move it 
to a message category named '*WxWidgets' (case doesn't matter). You 
might want to go into preferences and enable drag and drop for this task.

After you do all that, open up a monticello browser, select your 
package, and hit the 'Browse' button. Every time you "save" your package 
from the Monticello browser, it does a snapshot and keeps track of all 
the diffs from version to version. No more ChangeSet spelunking.

Once that's done, I can write you a little utility method that bundles 
up the current monticello snapshot of WxWidgets into a SAR (if you want).

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

Yep. Also, for deployment, stripping WxWidgets down for a given app will 
probably be a much more tractable problem than stripping squeak in 
general has traditionally been. (famous last words).

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

No sweat, I'm glad to see it might get in.

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

With the exception of #onMenu:send, they look pretty good to me. Not 
sure if I got your point here.

For menus in specific, however, it's a bit messy. How's about changing 
code that looks like this:

	menu
	  append: 101
	  item: '&Mercury'
	  helpString: 'This is the text in the statusbar'.

Too look like this:
	menu appendItem: (WxMenuItem
	  label: '&Mercury'
	  sel: #onMercury:)

or for more control, this:
	menu appendItem: (WxMenuItem
	  label: '&Mercury'
	  helpString: 'This is the text in the statusbar'
	  target: self
	  sel: #onMercury
	  deferred: true).

The menu's #appendItem: method can assign an id number and keep a 
private dispatch dictionary mapping id numbers to WxMenuItems. That way 
you don't need all those "self onMenu: 301 send: #onMenu301To303:" commands.