> On 03-Jul-05, at PM 12:09, Blake wrote:

>> I have a project right now I'd like to do in seaside, but it requires 
>> me to be able to read and display a table on the web, something easily 
>> done in other environments, but not in Squeak.

I would like to extend Blake's point: there are even more aspects that
should be fulfilled by Squeak if its 'general acceptance' IS a target
for its development team.

At the moment Squeak is a rather exotic, although sympathic
environment for Smalltalk afficionadios. Although Smalltalk itself is
a clean language with well-defined boundaries, the extravagancy with
which Squeak handles GUI is a rip-off...

The MVC-based GUI solution seems to be a bit outdated by Morphic but
Morphic is _highly_ undocumented, it has hardly any usable, general
purpose and good-looking widget set. If Squeak would like to remain
the secret weapon for creating interactive electronic dashboards for
4-8 year old schoolboys (no one older would really appreciate such
primitive graphics in the days of alpha blending, glass effect widgets
a la Tiger etc. - sorry for the hard expression), so be it. On the
other side, if Squeak would like to step up and earn some limelight in
the general programmers' population, definitive steps should be
undertaken to make its graphical subsystem on par with (or at least
approaching to) e.g. Qt, wx or Java foundation classes.

wxSqueak is a heroic effort (kudos Rob Gayvert !!!) but it has
inherent weaknesses in the deployment area: Squeak has by-nature a
HUGE footprint base system (by 'base' I do not mean barely usable ;-)
which could be done by shrinking the image into only 3-4 MBs), wx
libraries may add a factor of two to overall package size, not to
count the mixed licensing situation.

A modern, native GUI subsystem would be great in Squeak, as well as a
fine-tunable shrinking system which clears the deployment image on a
per-module basis.

I would really like to see Squeak growing and taking the right
direction in the future!

Cheers,
Geza