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.

[Rob Gayvert]

Post by Steven Swerling
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.

Post by Steven Swerling
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.

Post by Steven Swerling
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.

Post by Steven Swerling
[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?
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
(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

[Steven Swerling]

Rob Gayvert wrote:

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

Post by Rob Gayvert
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).

Post by Rob Gayvert
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).

Post by Rob Gayvert
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.

Post by Rob Gayvert
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.

[Cees de Groot]

Post by Steven Swerling
Off topic: I like your "Presenter" architecture. Clean.

It's very much on topic because:
a) I think the tools should provide clean examples of how UI's 'should' be
developed with wxSqueak
b) They provide a good basis for a ToolBuilder port, something still on my
todo list.
(the only drawback is that I think the classes should get prefixed names,
they stand a reasonable chance of conflicting as they are).

Post by Steven Swerling
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.

+1. The juggling of integers disturbed me as well, but not enough yet to
build a general solution for it...

I'll try to load our stuff into a 0.4 image ASAP...

[Rob Gayvert]

On Tue, 22 Feb 2005 19:09:24 -0500, Steven Swerling

Post by Steven Swerling
Off topic: I like your "Presenter" architecture. Clean.

a) I think the tools should provide clean examples of how UI's
'should' be developed with wxSqueak
b) They provide a good basis for a ToolBuilder port, something still
on my todo list.
(the only drawback is that I think the classes should get prefixed
names, they stand a reasonable chance of conflicting as they are).

Agreed on both counts. I haven't done anything at all with the tools for
0.4, but I should at least rename them to be consistent. All the other
classes I've introduced are Wx-prefixed, so these should be as well.

Any news on the UIManager front? I just went through all of the hacks I
added to the system classes to make the wx-tools work. What a mess.

[Cees de Groot]

Post by Rob Gayvert
Any news on the UIManager front? I just went through all of the hacks I
added to the system classes to make the wx-tools work. What a mess.

Well, ToolBuilder/Manager mostly works. The only thing left is to add
wxSqueak support - roughly a 'master class' and a class per widget that
ToolBuilder needs. No more hunting through the image.

ToolBuilder is on SqueakSource, btw.

[Rob Gayvert]

Post by Cees de Groot

Post by Steven Swerling
The menu's #appendItem: method can assign an id number and keep a
private dispatch dictionary mapping id numbers to WxMenuItems. That
#onMenu301To303:" commands.

+1. The juggling of integers disturbed me as well, but not enough yet
to build a general solution for it...

My concern about the #on:send: methods is that I haven't looked at this
whole area from a Smalltalk viewpoint. All I've done so far is
transliterate a bunch of C++ and wxPython examples into Squeak code that
works. Hence, you wind up with some rather weird stuff like
#onMenu301To303:. And I'm not sure I understand all of the capabilities
of the whole wxWidgets event model either, so I'm not sure if things
like ranges and custom events and pluggable handlers are represented
properly. And do we ever really need ids? They strike me as ugly, but
there might be situations where you need them.

In short, before we go off and write gobs of code that call the existing
methods, I think it would be worthwhile to discuss what the best model
for Squeak would be.

[Steven Swerling]

Post by Rob Gayvert
My concern about the #on:send: methods is that I haven't looked at this
whole area from a Smalltalk viewpoint. All I've done so far is
transliterate a bunch of C++ and wxPython examples into Squeak code that
works.
Hence, you wind up with some rather weird stuff like
#onMenu301To303:. And I'm not sure I understand all of the capabilities
of the whole wxWidgets event model either, so I'm not sure if things
like ranges and custom events and pluggable handlers are represented
properly. And do we ever really need ids? They strike me as ugly, but
there might be situations where you need them.
In short, before we go off and write gobs of code that call the existing
methods, I think it would be worthwhile to discuss what the best model
for Squeak would be.

The proof is in the pudding -- you made the right choice for
bootstrapping Wx into squeak. If I accurately detect a note of concern
on your part that people might consider the current layout to be your
idea of what Smalltalk code should look like, why not just say "caveat
emptor", and permit yourself a free hand to revise and rearchitect as
you see fit, when you feel the time is right. Those of us that rely on
your work will just have to roll with the motion, chime in with
opinions, and keep up as best we can.

[Rob Gayvert]

Post by Steven Swerling

Post by Rob Gayvert
My concern about the #on:send: methods is that I haven't looked at
this whole area from a Smalltalk viewpoint. All I've done so far is
transliterate a bunch of C++ and wxPython examples into Squeak code
that works. Hence, you wind up with some rather weird stuff like
#onMenu301To303:. And I'm not sure I understand all of the
capabilities of the whole wxWidgets event model either, so I'm not
sure if things like ranges and custom events and pluggable handlers
are represented properly. And do we ever really need ids? They strike
me as ugly, but there might be situations where you need them.
In short, before we go off and write gobs of code that call the
existing methods, I think it would be worthwhile to discuss what the
best model for Squeak would be.

The proof is in the pudding -- you made the right choice for
bootstrapping Wx into squeak. If I accurately detect a note of concern
on your part that people might consider the current layout to be your
idea of what Smalltalk code should look like, why not just say "caveat
emptor", and permit yourself a free hand to revise and rearchitect as
you see fit, when you feel the time is right. Those of us that rely on
your work will just have to roll with the motion, chime in with
opinions, and keep up as best we can.

Fair enough. I'll keep plugging away at the lower level capabilities
(there's still a long way to go ;)). And if anyone comes up with a
better higher level scheme, I'll certainly be open to it.

[Rob Gayvert]

Post by Steven Swerling

Post by Rob Gayvert
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.

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

Okay, steps 1-3 were easy, and now I have this nice view of everything
in a SnapshotBrowser. The classes in *Extensions are slow to browse, but
other than that it's great. Could you whip up a bundle script for this?

[Cees de Groot]

Post by Rob Gayvert
Okay, steps 1-3 were easy, and now I have this nice view of everything
in a SnapshotBrowser. The classes in *Extensions are slow to browse, but
other than that it's great. Could you whip up a bundle script for this?

Of course, you don't need to do a lot more than this. Most modern Squeak
images should have MCInstaller so they can load straight Monticello files.

Monticello has the nice property that every version is completely
self-contained: it has the full code, and information about its ancestry.
So if you save the MC file to a repository, you can then put it up for
download, I can grab and install it, and send you sensible patches from
there.

[Steven Swerling]

***(Provisional) Instructions for Building WxSqueak v0.4 using MSVC 6***
[Aside: Rob, for v 0.3, you said it was necessary to make the following
change to WxWidgets' source:
src\common\event.cpp, line 1000:
if (entry->m_callbackUserData && (entry->m_callbackUserData != this))
I left this in for my build of v0.4. Not sure if it's still needed --
can you comment?
]

This is adapted from my instructions for building v0.3. The latest
version of Rob's msvc workspace was cleaned up a lot, so I didn't really
have to do anything but open up the workspace, remove the B3D plugin,
and compile. I think the instuctions will get you most of the way there,
but I may be assuming some changes that I made to WxWidgets and since
forgot.

1. Make sure you have msvc security pack 6 installed. see

http://msdn.microsoft.com/vstudio/downloads/updates/sp/vs6/sp6/default.aspx)

(this may not be mandatory, but if you get a bug during compile that
tells you to contact Microsoft Technical support, chances are that this
will solve the problem).

2. Get Rob's src for WxSqueak:
http://homepage.mac.com/rgayvert/wxsqueak0.4rc1-win32-src.zip

(You might want to check Rob's wxsqueak page to make sure this is
up-to-date when you read this)

3. Install wxWidgets 2.5.3 for windows (MSW). ***DONT BUILD IT YET***

Download it from:

ftp://biolpc22.york.ac.uk/pub/2.5.3/wxMSW-2.5.3-setup.zip

4. Define environment variable WX253 to point to your root directory for
WxWidgets 2.5.3 (Start
Menu->MyComputer->properties->advanced->Environment Variables).

5. Make the following changes to the file

"${WX253}/lib/vc_lib/msw/wx/setup.h"

(if there is not already a "setup.h" in that folder, that may be because
you haven't built WxWidgets yet. WxWidgets' make file moves a lot of
files around the first time it's run. If this is the case, build
WxWidgets immediately [see step 6 below], then come back here and make
the changes below, then build WxWidgets again).

Change the following #defines in "setup.h" (they are defined as '0' be
default):

#define wxUSE_DISPLAY 1
#define wxUSE_GLCANVAS 1
#define wxUSE_POSTSCRIPT 1


6. Now you have to build WxWidgets. Follow WxWidget's instructions for
this. Briefly, load up the file ${WX253}/build/msw/wx.dsw into msvc 6,
choose Build->Batch build, and have it build *everything*. Once the
build looks like it's going good, go take a break, the build takes
awhile. For full build instructions, see "Start Menu -> All Programs ->
wxWidgets 2.5.3 -> Compiling WxWidgets".

7. After doing the full build, you need to build a couple more libraries
that will be needed later by WxSqueak:
a. In contrib/build/stc, load in the stc.dsw workspace, and build the
stc library (make sure active build target is Win32 Debug). The result
will be placed in ${WX253}/lib/vc_lib/wxmsw25d_stc.
b. In contrib/build/plot, load plot.dsw and build the plot lib
(again, make sure active build target is Win32 debug). Result also
placed in vc_lib (as wxmsw25d_plot.lib).

8. Load up Robs msvc workspace file, located in
[wxSqueak src root]\platforms\win32\misc\wxsqueak.dsw

9. Set the active configuration for a Debug build (Build Menu->Set
Active Configuration->Squeak win32 Debug).

10. I had to remove B3DAcceleratorPlugin from the Plugins (internal
plugins) list. Not sure what the problem was, but I didn't feel like
figuring it out for now. Just skip it if you want by going to the
"FileView" project tab, expand the "Plugins (internal plugins)" folder,
and deleting the B3DAcceleratorPlugin folder from your project. If you
get it to build with B3D, perhaps you might tip me off as to how you did it.

That's what it took for me. Now hit F7 and build it. The wxSqueak.exe
file will be deposited in
[you're wxSqueak root]\platforms\win32\Debug

Good luck,
Steve S.