>Another, entirely unrelated question is: How do I start writing a
>"classical application". I.e. something with a polished, shiny user
>interface, where the user isn't aware that he's doing Smalltalk (other
>than, of course, in an About box where Squeak is listed among the
>credits)?

That's not easy with Squeak as one requirement would be a "polished" and
"shiny" GUI which IMHO Squeak doesn't have.  If you're comfortable with
Windows applications, Dolphin Smalltalk (www.object-arts.com) might be a
better tool.  DS is free until you want to actually deliver an application.
 In that case, you've to buy an application deployment kit.

If you still want to use Squeak, you've to create your own framework.
Fortunately, this isn't as difficult in Smalltalk as you might think.

Second, Squeak isn't very good in interacting with other tools.  It
completely ignores the hosting operation system and does what is does on
its own (Newest example is true type support - really cool but the
reinvention of the wheel).  Interaction is of course possible but again
you'd have to do it on your own.

Squeak, as I think most people see it, is a toy, a playground for new
ideas. It's not meant as an (rapid) application development system.
Nothing against that.

However, I see a demand for a second kind of Squeak.  A Squeak tailored as
a tool - not a toy - for creating applications (games, financial programs,
other tools, whatever).  Something like a free alternative to other
commercial Smalltalk systems.  Something, which not only awakes warm
feelings in the heart of true Smalltalkers but which attracts even ordinary
people ;-)

Here's a sketch of a system (actually the changes that are needed to be
applied) that IMHO is better suited to fullfill this.

The system architecture is based on a micro kernel which can be extended
with binary modules.  There's still an image for development, but the
deployment version will be created from modules.  Name spaces help to build
independent modules.

A small core without GUI can read in and process Smalltalk files.

There's more than one Screen possible and Screens can be manipulated from
Squeak - this would allow a multiple window application with keeping
compatibility with the old system.

Optionally, a high performance full screen mode (based on DirectX on
Windows for example) can be used for other kinds of applications (games,
for example)

There's a Swing (a platform-independent Java-GUI) like GUI for Smalltalk.
As GUIs are one of my favorite interests, I could write more about this in
a different article.  The GUI should be event driven and very easy to use.
In contrast to traditional GUI frameworks, it should use the idea of
Morphic or the Oberon System/3 system of directly manipulationable widgets
which would make a separate GUI builder superfluous.  I was very impressed
when I saw a demo of the phaidros' Jump system - they use the same idea.

Other modules should offer networking or database support.

The system needs a full documentation of all public methods and a strict
separation of public and private methods, similar to the JavaDoc output.

The system should stay as compatible as possible with both the ANSI
Smalltalk and the existing Squeak system (in this order).


Comments?
bye
--
Stefan Matthias Aust  //  Don't talk.  Just doIt.