Stefan Matthias Aust wrote:

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

Sounds very much like VisualWorks (e.g. with the openness being provided by
VisualWorks Non-Commercial).

Parcels provide fast-loading binary modules.

VW has name spaces arriving in the next release (see
http://brain.cs.uiuc.edu:8080/VisualWorks.NameSpace+Draft).

Headless images can load parcels.  We have a web-browser plug-in under
construction that will be released this year.  It has a smallish base image,
not by Squeak standards, but it should be possible to get below 2 megabytes.
The next release won't have much in the way of base image decomposition because
of time pressure.  But we should do better later in the year when Opentalk is
released.

The VW GUI already supports multiple screens in X.

JUN is an example of a good 3d graphics system, but its not hugely fast and
hasn't yet been ported from Windows.

Swing has lots in common with VW's graphics framework, unsurprising as
ex-ParcPlace GUI people worked on it.

VW has networking and database support, among other interconnection facilities.

Documentation gets the standard school report "could do better".

ANSI conformance is in progress.  We have the exception system done.


But there are other issues.  To be a good citizen within a conventional OS,
interacting with other tools Smalltalk needs both much faster start-up times
(of the order of a few milliseconds, rather than a few seconds) and a call-in
API.

Faster start-up times can be achieved with a small image.  Another alternative
is configuring Smalltalk as a compute server, where a Smalltalk process is
always running in the background.  But current systems don't support multiple
independent computations well; class libraries are not thread-safe, and there
is no support for private class libraries, independent base modification, etc.
But this approach is feasible if suites of applications are designed with
co-habitation in mind.

The call-in API really requires a threaded connection between Smalltalk and the
outside world.  I've done such a scheme for VisualWorks, packaging it as a DLL,
allowing call-ins from C.  But I've had no time to work on it and its still in
prototype form.

Another facility, provided by VisualAge Smalltalk, is being able to load code
by memory-mapping read-only sharable files.  This makes it feasible to have
large numbers of concurrent activations of a single image, where most code is
shared between each activation.

But to develop headless base images one really needs a remote programming
environment.  ParcPlace-Digitalk did work on something called Firewall
(actually Steve Messick's baby) which was aimed at producing very small
Smalltalk apps for delivery.  The remote GUI was connected to the virtual
machine, rather than to the image.  As such Firewall presented some
implementation challenges and with our internal problems the work was
discontinued.

But we are scheduled to release an alternative this year called Opentalk.  This
derives from Xu Wang's I3 (implicit interface invocation) work within DST which
provides Smalltalk-to-Smalltalk remote messaging without IDL.  As such it is
reminiscent of Smalltalk networking work done in the mid-eighties by people
like Bennet, except that I3 fits within DST's CORBA framework.  Opentalk uses
Smalltalk-to-Smalltalk communication over sockets (using a number of protocols
including broadcast and multicast).  The tool architecture is extended from MVC
to MVC-A, where A is an Agent that sits between the model and that which the
model manipulates.  The Agent is designed to be remotable.  So in the normal
base system one has a non-distributed local Agent and in Opentalk the same tool
connects to a remote image through a remote Agent with substantially the same
API.  Hence Opentalk provides a way of programming remote headless images.
_______________,,,^..^,,,_______________
Eliot Miranda, ParcPlace