NOTE -- TO SEE THE ENTIRETY OF THIS FILE...
Move the mouse into the rightmost part of the scrollbar, until the cursor changes to a menu-like icon.  Then click and hold down until you have selected the item, 'get entire file'.  If you then release the mouse button, you should see the entire contents of the ReadMe file.
--------------------


About Squeak in General
--------------------------------
             Squeak 2.3
    (c) 1996 Apple Computer, Inc.
     (c) 1997-1999 Walt Disney
       ALL RIGHTS RESERVED.
Squeak is a work in progress based on Smalltalk-80, with which it is still reasonably compatible.  Please see the various introductory windows for more information about this particular release.

The Interpreter
Squeak includes a complete simulation of its ObjectMemory, Interpreter, and BitBlt, each of which began with the "Blue Book" spec.  The object memory is a completely new direct-pointer object model with compact headers and an incremental compacting garbage collector.  The interpreter has been worked over for efficiency, and improved handling of 32-bit LargeIntegers allows it to simulate itself at reasonable speed.  See the various class comments in the Squeak Interpreter category.  The Squeak system also includes a translator to C.  Together these can generate complete C source code for the interpreter.  If you take advantage of this capability to port the system to other platforms, we would like to hear about it.

Color graphics
Squeak's BitBlt has been retrofitted with support for variable-depth color and many performance enhancements.  It has several added functions including a paint mode that supports transparency, and an alpha-blend mode for 32-bit color.  It also has a "warp-drive" variant that will scale, rotate, and otherwise deform bitmaps in a single pass.  Interested users will want to try
	Display restoreAfter: [WarpBlt test1], and
	Display restoreAfter: [WarpBlt test3].
The warp drive is also capable of limited anti-aliasing.  You can compare the results by executing
	Display restoreAfter: [WarpBlt test12].
Two other demos of possible interest (see comments) are
	Display restoreAfter: [BitBlt alphaBlendDemo], and
	Display restoreAfter: [BitBlt antiAliasDemo].

Sound
Squeak includes base classes and some simple primitives that support real-time background generation of sound and music.  Interested users will want to try
	AbstractSound stereoBachFugue play.
Squeak also includes a MIDI file reader.  If you are connected to a network, you should try one of...
	MIDIFileReader playURLNamed:
	   'http://squeak.cs.uiuc.edu/Squeak2.0/midi/wtellovr.mid'.
	MIDIFileReader playURLNamed:
	   'http://squeak.cs.uiuc.edu/Squeak2.0/midi/toccFugueDmin.mid'.
If you're short on horsepower, you'll do better with...
	MIDIFileReader playURLNamed: 
	   'http://squeak.cs.uiuc.edu/Squeak2.0/midi/tlmnflut.mid'.

Morphic
Morphic is a completely new graphics framework for Squeak.  Examples can be explored in the 'Play With Me' windows, or by following the accompanying Morphic scripting tutorial.  We have loaded lots of things into Morphic.  It's a little cluttered and a bit slow, but it's an architecture we like, and we'll be cleaning it up and tuning it over the next year.

Balloon
Squeak now includes a completely new outline-based graphics subsystem named Balloon.  Balloon graphics are independent of scale and rotation, and may be rendered simply or with 2 degrees of anti-aliasing.  For a quick demonstration, execute...
	(FlashMorphReader on: (HTTPSocket
		httpGet: 'http://www.audi.co.uk/flash/intro1.swf' 
		accept:'application/x-shockwave-flash'))
	processFile.
This example also demonstrates that Squeak includes a fairly complete implementation of the ShockWave graphics file format, with conversion to Balloon graphical objects.  Since it's all in Squeak, you can stop the player and take apart the morphic balloon objects.

Balloon has also been interfaced to TrueType outline fonts.  There is an example in Play With Me - 3 (This uses 16-bit color).

Networking
This version of Squeak supports sockets.  If you are on a web-connected network, you might want to try...
	HTTPSocket httpShowGif:
		'http://squeak.cs.uiuc.edu/Squeak2.0/midi/Squeakers.GIF'.
There are many more examples in the Socket class.

Also included with this release is a complete WikiWiki server.  See the accompanying information on WikiWiki.

Squeak's FileList has also been extended with network access.  This feature is newly added, and will probably require a little shaking down and tuning.

Speaking of network access, we hope soon to eschew all these informational windows in favor of a simple link to a Squeak Wiki full of useful and up-to-date information about the latest release.

NOTE: The Comic Sans font included in this release is copyright: © 1997 Microsoft Corporation. All rights reserved.  Use is governed by the agreement found at
	http://www.microsoft.com/typography/fontpack/eula.htm
Copies of this font may not be distributed for profit either on a standalone basis or included as part of your own product.  It is our intention to replace this font with a public domain font in the near future.


The Squeak User Interface
----------------------------------
The Squeak Screen
To resize the Squeak Screen, click and drag the bottom right corner (just pretend it has a grow box), and then choose 'restore display' from the screen menu.  We'll clean this up soon.

Windows
To close a window, click in the left box of its title bar.  To collapse or expand a window, click in the right box.  To change the name of a window, click in its title, and edit the name in the resulting dialog box.

Windows can be moved by dragging their title bar, provided that you click in the shaded regions.  To change the size of a window, move the mouse near a corner or border and, when the cursor changes, click and drag.

Panes
Many windows are made up of panes, and many of these have scroll bars on the left (naturally - that's where most text is ;-).  Scroll bars are divided into 4 narrow strips, and the cursor changes to tell you which reagion you are in.  Three cursors inform you of normal up/down/jump scrolling (try them now), and the fourth indicates availability of a pop-up menu relating to the pane you are in.

Menus
Pane menus (often different in different panes) can also be invoked by option-click (and hold) in most panes, and window menus can be invoked by cmd-click.  Many menu commands can also be invoked by cmd-key combinations, indicated in the menus.  The global 'screen menu' can be invoked simply by clicking in the gray area within the Squeak screen, but outside any Squeak windows.

Color
Squeak graphics support 1, 2, 4, 8, 16, and 32-bit color.  To change the resolution of the Squeak screen, execute any of
	Display newDepth: 1.
	Display newDepth: 2.
	Display newDepth: 4.
	Display newDepth: 8.
	Display newDepth: 16.
	Display newDepth: 32.
Note that common choices are available in the screen 'do...' menu.  Naturally, you will want some reasonable correspondence between this choice and the setting of your monitor.

The screen will consume more memory in higher resolutions, but Squeak is careful to use only 1-bit pixels for most text window images.  The window menu offers a choice whether to save only two colors or all colors of a given window (as well as a coice of background shade).

Projects
Project windows are actually more like doors than windows, since you can enter them by clicking in the interior.  You can create new ones by choosing 'open...project' from the screen menu.  To exit a project (and return to its containing project), choose 'exit project' from the screen menu.  Each project maintains its own set of windows, its own set of changes, and its own screen color depth.

Typing
The _ character in Squeak is really an underbar; that's how you type it.  Note that := is an acceptable alternative for assignment.

The Squeak text editor supports many editing operations that can be invoked by command keys.  For a full list of these operations, choose 'help' from the screen menu, then choose 'command-key help'


Managing and Saving Changes
-------------------------------------
Starting and Quitting
Obviously you have figured out how to start the system.  The approved method is to double-click on an image, although if you have several different interpreters, you may want to drag the image to the appropriate interpeter.

To quit a Squeak session, choose 'quit' with or without saving from the screen menu.  If you save, your image file will be overwritten.  You may choose 'save as...' to write a newly named copy of your image and changes (see below).

Image File
All of the objects -- classes, dictionaries, windows and other objects that make up the Squeak environment are stored in an image file (this must always be named 'SomeName.image').  For this reason, when you start up an image, everything is right where you left it when you last saved the image.

Sources and Changes
For various reasons, the source code associated with the image is stored in two other files.  The code of the system as originally delivered (vers 2.0) is stored in the file 'SqueakV2.sources', and the sources for everything done since that time is in the changes file (which must similarly be named 'SomeName.changes').

Storing the source code in a separate file has several advantages.  To begin with, if you have been working for a couple of hours, and your dog rolls over the power cord, you will still have a sequential record of all your program edits, and these can be perused and replayed with numerous tools such as changes: post-snapshot log.  This feature has also saved many a hacker who got too adventurous in changing the system he or she was using.

Also, if you wish to run the system with severely limited resources, it can be operated without any source code, owing to its ability to decompile the bytecode methods into a readable and editable version of the original source code (only comments and temporary variable names are lost).

Finally, since the changes file does not consume memory space, Squeak keeps a continuous log of all your program changes, and these can be examined and reinstated at any time (see 'versions' option in browser selector pane).

FileOut, FileIn
In addition to the 'save' command that saves the entire state of your Squeak image, individual methods, categories and classes may be 'filed out'.  This option is available in most browsers, and it results in the creation of a text file with an appropriate name, incorporating the code in question.

The format of this file is special, in that it can be read back into the same or another Squeak image to recreate those same classes and methods in a new environment.

ChangeLists, ChangeSets, and ChangeSorters
A ChangeList is a method-by-method view of a fileOut.  Note that the changes-file record of all your program edits uses the same fileOut format, so a ChangeList can browse the change history of any Squeak session.  The recent change log option of the changes... menu is one example; other examples in ChangeList public access include viewing other Smalltalk source code files.  This can be easly invoked  through the FileList 'browse changes' option.

In addition to the sequential changes-file record of all changes, whatever project you are in, a ChangeSet keeps a more dictionary-like record of what has been changed.  This allows you to fairly easily make a fileOut of just the most recent versions of a bunch of related changes that constitute your work on that project.

ChangeSorters allow one to organize all system changes into a number of independent ChangeSets.  One word of caution: at the present, unaccepted changes in a changeSorter window will be lost if you exit the window and return later, due to over-ambitious automatic updating.

Projects offer a natural way of organizing related work, windows and changeSets.  The effect is almost like many separate images in one, except (!) that all projects share the same code, regardless of where else it may be changed.

Organizing your Disk (on the Mac)
Squeak will look for its sources file both in the folder in which the image was started, and in the folder in which the VM exists.  It is simplest to put the sources together with the VM, and then you can use any numbe of image/changes pairs anywhere on your disk.

If you wish to maintain  different versions of the VM on your disk, here is the easiest way:  put all VMs in a single folder, along with the sources.  Then in any folder with images for version X, put an alias of the VM for version X, and drag your image onto the VM alias to start it.


How Squeak Finds Source Code
-----------------------------------
Starting and Quitting
Obviously you have figured out how to start the system.  The approved method is to double-click on an image, although if you have several different interpreters, you may want to drag the image to the appropriate interpeter.

To quit a Squeak session, choose 'quit' with or without saving from the screen menu.  If you save, your image file will be overwritten.  You may choose 'save as...' to write a newly named copy of your image and changes (see below).

Image File
All of the objects -- classes, dictionaries, windows and other objects that make up the Squeak environment are stored in an image file (this must always be named 'SomeName.image').  For this reason, when you start up an image, everything is right where you left it when you last saved the image.

Sources and Changes
For various reasons, the source code associated with the image is stored in two other files.  The code of the system as originally delivered (vers 2.0) is stored in the file 'SqueakV2.sources', and the sources for everything done since that time is in the changes file (which must similarly be named 'SomeName.changes').

Storing the source code in a separate file has several advantages.  To begin with, if you have been working for a couple of hours, and your dog rolls over the power cord, you will still have a sequential record of all your program edits, and these can be perused and replayed with numerous tools such as changes: post-snapshot log.  This feature has also saved many a hacker who got too adventurous in changing the system he or she was using.

Also, if you wish to run the system with severely limited resources, it can be operated without any source code, owing to its ability to decompile the bytecode methods into a readable and editable version of the original source code (only comments and temporary variable names are lost).

Finally, since the changes file does not consume memory space, Squeak keeps a continuous log of all your program changes, and these can be examined and reinstated at any time (see 'versions' option in browser selector pane).

FileOut, FileIn
In addition to the 'save' command that saves the entire state of your Squeak image, individual methods, categories and classes may be 'filed out'.  This option is available in most browsers, and it results in the creation of a text file with an appropriate name, incorporating the code in question.

The format of this file is special, in that it can be read back into the same or another Squeak image to recreate those same classes and methods in a new environment.

ChangeLists, ChangeSets, and ChangeSorters
A ChangeList is a method-by-method view of a fileOut.  Note that the changes-file record of all your program edits uses the same fileOut format, so a ChangeList can browse the change history of any Squeak session.  The recent change log option of the changes... menu is one example; other examples in ChangeList public access include viewing other Smalltalk source code files.  This can be easly invoked  through the FileList 'browse changes' option.

In addition to the sequential changes-file record of all changes, whatever project you are in, a ChangeSet keeps a more dictionary-like record of what has been changed.  This allows you to fairly easily make a fileOut of just the most recent versions of a bunch of related changes that constitute your work on that project.

ChangeSorters allow one to organize all system changes into a number of independent ChangeSets.  One word of caution: at the present, unaccepted changes in a changeSorter window will be lost if you exit the window and return later, due to over-ambitious automatic updating.

Projects offer a natural way of organizing related work, windows and changeSets.  The effect is almost like many separate images in one, except (!) that all projects share the same code, regardless of where else it may be changed.

Organizing your Disk (on the Mac)
Squeak will look for its sources file both in the folder in which the image was started, and in the folder in which the VM exists.  It is simplest to put the sources together with the VM, and then you can use any numbe of image/changes pairs anywhere on your disk.

If you wish to maintain  different versions of the VM on your disk, here is the easiest way:  put all VMs in a single folder, along with the sources.  Then in any folder with images for version X, put an alias of the VM for version X, and drag your image onto the VM alias to start it.


Pluggable Views
--------------------
Version 2.0 of Squeak includes a complete rewrite of all the MVC windows to use pluggable views.  A pluggable view has a set of selectors that parameterize its model interface in such a way that instances of the same view class can be used on many different models.  This simplifies and factors the system -- we were able to reclaim about 50 classes (!) from the old MVC system in the course of this rewrite.  More importantly, it left us with only a handful of classes to convert in order to run all our existing development system in a morphic-only world.  Nearly the entire view mechanism has been funnelled down to
	PluggableListView
	PluggableTextView
	PluggableButtonView

for which we have written morphic counterparts,

	PluggableListMorph
	PluggableTextMorph
	PluggableButtonMorph.


Morphic Squeak
--------------------
It is possible in Version 2.0 to run the entire Squeak development environment in morphic.  You do this by opening a morphic project, and choosing 'windows...' from the morphic world menu (use ctrl-click).  This part of the system is still smoking -- essentially none of it existed a month ago.  Some parts are slow, some parts may fail, but we feel it is instructive to see an entirely new viewing mechanism running the same old MVC applications.


Scripting and End-user Access
------------------------------------
Squeak Version 2 includes sketches of two entire end-user programming paradigms, intregrated with the morphic environment.

One is a wiring metaphor inspired by Fabrik, that allows simple component assembly to be performed the way you put a stereo system together. The implementation is just a toy (no real dataflow model or encapsulation yet) but you may enjoy the demonstration in Play With Me - 6.

The other is a tile-based interface that offers viewers and scriptors as iconic and active counterparts to Squeak's textual and more passive inspectors and browsers. It has been taken fairly far in a number of directions, as you may discover by following the introductory tour "Programming in Morphic".


As an explorer of Squeak, you need to know that these environments are only sketches. We are excited about them. We are working actively on them. But they are not complete, they are not foolproof, and they are not well documented (but then what is?). We share them in the same spirit that we share Squeak: we invite you to play with us, to share our discovery, and perhaps to work with us as we move forward.



Programming in Morphic


Two quite different styles of programming in Morphic are available in Squeak 2.0: "Classic Morphic Programming" and "Scripting with Players".


(I) Classic Morphic Programming

This is the kind of programming for which Morphic was originally designed, and excellent examples of clean and attractive style using that approach can be found, for example, in BookPageSorterMorph and EnvelopeEditorMorph.

In "Classic Morphic Programming" style, you define your own subclasses of one or more generic Morph classes, and blend them into a working subsystem. Here, you're directly extending Morphic, in grand and time-honored Smalltalk manner. The fundamental tool here is the Browser: you locate and familiarize yourself with particular Morphic classes, and you then subclass the ones that you decide are appropriate for your application.

Most current Squeak users will prefer this traditional, mature, analytic, browser-based Smalltalk approach,

If you're still curious about the other style, read on...


(II) Scripting with Players -- The "User-Scripting" Style

The second style of programming is rather more informal, more like "scratch programming", somewhat comparable to what we Smalltalkers do when we use a Workspace to construct and evaluate various lines of code for some exploration or calculation in Smalltalk, and also comparable to the kind of scripting done by users of systems like HyperCard and HyperStudio, etc.

In the User-Scripting style, you construct surface graphics by directly assembling standard Morphic parts -- e.g. Rectangles, Images, Joysticks, etc., by dragging them from a Parts Bin and arranging them as desired, and then you add user-defined state and behavior by adding instance variables and writing methods for "Players" who represent the individual morphs you wish to script.

The user thus does not directly subclass any particular kind of Morph, but rather she assembles? Morphs and gives them special state and behavior by associating them with "Players", which are the fundamental user-scriptable object types for User Scripting.

(The basic hookup is that every Morph can have, optionally, a Player as its "player", and every Player has an associated Morph that it "wears" as its "costume". Player itself is a class with lots of capability but very little instance state; user-defined Players are all implemented as compact, single-instance subclasses of Player.)

--------------------------------------------------------

Blanket Disclaimer and Warning

In Squeak 2.3 we offer only a very early take on User Scripting. It has many rough edges, consumes lots of memory, can leave garbage around that will bloat your image,

It is tempting to dwell at length on "Disclaimers" about User Scripting, but we shall resist, beyond saying: this is early work, preliminary, much in flux, with bugs, inconsistencies, significant gaps in design, and much that definitely will be changing before long.

If you wish to play with this stuff anyway, please do so in a spirit of high adventure, and be sure to protect yourself by doing your exploring in a "throw-away" copy of your image, not in something you intend to save and build on. These are very early days!


Live Examples Coming Later

In due course, we will be placing on the Squeak web site some "live examples" of use of "Player Scripting".

Eventually, we expect that full, interactive, mutlimedia-based Squeak tutorials, constructed entirely within the User Scripting domain, will be downloadable from the Web and will be immediately active and usable.

Technical limitations have kept us from doing that now, and space considerations have kept us from implanting live examples in this release image.

Good advice for the moment (except for the most adventurous) is to wait until those live examples are available on the net. They should make it much easier to absorb the basics of user-scripting, without having to wade through so much prose.

--------------------------------------------------------

The Three Basic Elements of User Scripting are:

(1) The "Halo" -- lets you interact with any object you can touch (i.e., any morph).

Alt-Click on a morph to bring up its halo. Successive alt-clicks will transfer the halo to the next morph in the hierarchy -- experiment with this. Mouse over the various halo handles and read the help-balloons that will pop up to explain what each handle does. The name of the object that currently bears a halo will be seen at the base of its halo (and a click on the name will let you edit it.) Note: on a Mac, Alt-Click is Apple-Click.


(2) The "Viewer" -- a dynamic graphical Inspector and Browser.

To get a Viewer for an object, drag from the cyan handle of its halo, and a Viewer will stick to the mouse; place it wherever you wish.

Use the top part of the viewer to see and change properties of the object; use the bottom part of the viewer to see and invoke scripts for the object. And use the buttons provided to add your own instance variables and your own methods to the object.


(3) The "Scriptor" -- a place to define, edit, test, save, and schedule actual scripts.

In order to succeed with user scripting, you will need to be able quickly to get a Halo on any object, open a Viewer on any object, and get a Scriptor for any object.

--------------------------------------------------------

Here is a suggested path to get started with scripting:


Preliminaries

Choose "project (construction)" or "morphic construction window" from the "open new" menu. Drag a Playfield (light green rectangle) from the parts bin and drop it somewhere. Drag a Star from parts bin, and drop it in the Playfield. Alt-click on the star to bring up its halo. Tear off a "viewer" for the star by dragging from its cyan halo handle. Drop that viewer somewhere nearby (but preferably NOT in the Playfield)

Balloon help over the various crude controls in the Viewer will give you a general orientation.


Exercise 1 -- Relationship between an object and its viewer.

a. Play with the star via its halo. Drag it around, rotate it, resize it, change other things via its red-dot halo menu, and watch the changes in the viewer. (You may need to click to another "bank" of parts to find the group of information you're interested in; use the little left and right arrows )

b. Play with the star via its viewer -- set its heading, its scale factor, its border width, its color, etc., and notice the effects on the star itself.

Anything you can manipulate in the viewer can also be manipulated via scripts, and the viewer gives you access to scripting, as will be seen below.


Exercise 2 -- Sending requests directly to an object from its viewer.

In the lower part of the viewer are some sample lines of script. (Look at the other banks to see the full vocabulary.)

You can click on any of the yellow "run it!" (exclamation point) buttons to send that line of command to the star. You can change the values of parameters there in the viewer.

Make the star turn by hitting ! for "star turn by 5". Hold down that ! button to keep the star turning. Change the "5" to larger and smaller values, and to negative values (by clicking on the little carets that control these things) and notice the effect

We're not "scripting" yet because we're still manually issuing one command at a time. Scripting is simply the process of assembling a sequence of such commands in a "Scriptor", so they will all run, in sequence, when asked.


Exercise 3 -- Making a simple script

Drag from the "star turn by 5" line of the viewer, and drop onto the "desktop" of the world. A Scriptor will result -- your own script, with the "star turn by 5" command already in there as its first line.

Drag from the "star forward by 5" line of the viewer, and drop that down inside the same Scriptor. You have now created a two-line script, that tells the star to turn and move forward.

Let the cursor drift over each of the five buttons at the top of the Scriptor, and read the balloon help of each to get an idea of what they do.

Click on the "!" and the script runs. Hold down, it keeps running. Change the amount-to-turn-by and the amount-to-move-forward-by and run again.

Now try out various alternatives for when? the script should run. Initially, when it says "Normal" in the Scriptor, it's just cold code waiting to be called by someone, such as by the yellow "!" button.

So now make it run continuously -- choose "ticking" from the script-status menu that pops up when you click on "Normal". The star should now start animating continuously, until you change its status or until you hit the "Stop" button.

While it's animating, change the parameters to "forward" and "turn" in the Scriptor, to achieve different curvature and speed as it putts along.

Now for fun you might find the "Pen" area in the star's Viewer, and change the star's "PenDown" to true. It will start laying down ink as it moves, and now by adjusting parameters to move and turn in the Scriptor, you can do a kind of scripted drawing.

Once you've started this, resist the temptation to change the pen's color and size in the viewer, because you might get distracted from the real business of scripting.

Exercise 4 -- Hooking up a script to the user interface

Above, you made the star's script "run all the time". Now go back to that same menu in its scriptor, and tell it to run on "mouseDown". Then mouse down on the star and watch the script run once.

Experiment with all the different choices -- mouseDown, mouseStillDown, mouseUp, mouseEnter, mouseLeave. For "countinuous controls" such as scroll bars and sliders, "mouseStillDown" is a good choice. For traditional "buttons", "mouseUp" is a traditional choice, though some controls feel better when they react on mouseDown.

You can have one script do something on mouseDown, and another on mouseUp, etc. One easy thing to try is to have the button change color (to something darker, for example) upon mouseDown, and then change back to its original color upon mouseUp.


Exercise 5 -- Naming and saving a script.

Thus far, we've been working with a "temporary script". If you want to make it a permanent part of the object, choose "name and save this script", and give it a name, such as "wander".

As soon as you've done this, you'll see "wander" show up in the star's Viewer, alongside "forward by", "turn by", "make sound", etc.

Your "wander" script has now become a formal part of the object -- you've added a method to your object. It can now be deployed in viewers and scriptors just like the system-defined scripts such as "forward by". And it can be called by any other script.

Exercise 6 -- Substituting your own (textual) Smalltalk code

Here we will make a button that, when pressed, files out your current change set. This is to illustrate the fact that you can always "escape" from the tile-scripting framework to write your own arbitrary Smalltalk code.

Get a parts bin.

Drag out an ellipse.

Drag out a "Text for Editing", and edit its text to say "File Out Changes".

Place the text over the ellipse, nicely centered (resize the ellipse as needed), then bring up the halo for the text and choose "embed" from its menu, and embed it in the oval

From the Text's halo menu, choose "lock", so that the label won't go into text-editing mode when the mouse comes down on it -- that's not what we want here.

Next, bring up the ellipse's halo and from the halo tear off a Viewer.

Name the ellipse "TestButton" (you can edit the name in the halo or at the top of the viewer).

From the viewer, tear off a "TestButton make sound croak" phrase, and drop it on the world's desktop. A scriptor opens up around it.

From the scriptor's menu, choose "name and save this script", and give it a name like "doFileout".

From the scriptor's status menu, change "normal" to "mouseUp". This will allow it to behave like a traditional button.

Test the button -- when you click on it, you should hear a croak sound.

Now chose "edit script textually" in the scriptor. This will give you a message-editing window in which you can type arbitrary Smalltalk code, and it will be invoked whenever the script is triggered, be it via ticking, mouse actions, or being called from another script.

So now we type in whatever script we want, in plain Smalltalk, and submit it. For the moment, you might edit the method to look like this:

doFileout Transcript cr; nextPutAll: 'Testing One Two Three...'. self beep: 'croak'.

Now make sure a Transcript is open, and then try the script out. When you click on the button, your message should show up in the Transcript and you should hear the croak.

This shows that the hookup is working. Now all that remains is to edit the method to do something useful; in this case, it will look like this:

doFileout Smalltalk changes fileOut. self beep: 'croak'

Now, whenever you click on this button, the current change set will be filed out and you will get a frogly confirmation.


(7) Adding instance variables to an object.

Hit the "add inst var" button in a Viewer to add an instance variable. The new instance variable starts out bearing a number, but you can change its type at any time. The type affects what form its readout (in the Viewer) will take, and also where you can drop a tile representing the value in a scriptor (numbers can be dropped on numbers, etc.)

If the type is a number, for example, you'll get a textual readout with arrows to change the values manually. But if the type is "player" (i.e. object-reference, or "alias", if you will), then the readout is a graphical thumbnail of the current referent.


(8) Scripting one morph to chase another

Get a morph (which you've named, say, "rabbit") busily animating with an ever-ticking script involving "forward by" and either "turn by" or "bounce".

Construct another Morph, name it "chaser" and script it to pursue the animating morph by giving it an ever-ticking script of the form:

chaser move toward dot

dot here refers to a little, faint object near the left edge of the window -- the one object in the world that starts out life with "identity", this serves as the sample parameter for any Player-valued scripting element, just like the "5" in "forward by 5" serves as a sample parameter for "forward by".

To make the object move not toward dot but rather toward the "rabbit" you've earlier animated, you'll want to tear off a tile to represent the rabbit. There is a handle on the left edge of the Halo which, when you mouse down on it, will yield you just such a tile. Get it, and drop it over the "dot" tile, and it will replace that tile, so that your script will now read:

chaser move toward rabbit

[For extra credit, you can adjust the speed at which pursuit takes place by adding a numeric slot to chaser and calling it "speed".]


(9) Controlling an object with a Joystick

Generally you create scripts by dragging tiles from the viewer; this gives you simple scripts (which already are syntactically correct, and are fully functional) to start out with, and then you proceed to modify them.

One essential operation is dropping a tile into another tile bearing the same type of information; this results in the old tile being replaced by whatever you dropped.

Thus, for example,

Paint an airplane using the simple painting tools:

Drag from the crude green arrow in a Parts Bin (which indicates "paint a new object") and drop somewhere on a Playfield. Paint a rough airplane-like figure facing upward, then hit the "Keep" button. This is your airplane. Open up its Viewer, and name it "airplane".

Make a script for the airplane that starts out: airplane forward by 5 airplane turn by 5

Get a fresh Joystick from the Parts Bin, and bring up a Viewer for it. Go to the parts bank that shows the joystick-specific parts, "leftRight", "upDown", "angle", and "amount".

Drag from the tile showing the word "leftRight"; tiles for "joystick's leftRight" will stick to the mouse.

DROP that "joystick's leftRight" directly onto the "5", to make the airplane's script read: airplane turn by joystick's leftRight

Now make this script run all the time ("ticking"), and you can spin the airplane by moving the joystick's handle to the left or to the right.

A simple extension (left to the reader) is to add a "forward by" command to the same script, and have the amount by which it is to go forward be obtained from some other number that a Joystick is able to report. It's fun to explore various possibilities for mapping the joystick parameters into the parameters for the "turn" and "forward" commands. Since the Joystick delivers four different numbers, you could hook them up to other things about your airplane (such as its color or its scale factor) and end up with some rather unusual controls!


More about Morphic scripting


About Assignment

The top part of the viewer consists of rows of the form:

airplane's heading <- 0.

If you drag from the green-and-purple left-arrow, you'll get an "assignment phrase", which is a line of code that lets you "assign a new value" for the heading. Plop it down in a script just like any other command.

Actually, there are four kinds of assignment: simple assignment, incrementing, decrementing, and multiplying; you move among them by hitting the carets on the assignment tile in the Scriptor. A simple exploration will reveal how they work, but be careful with the muliplying assignment -- your numbers can quickly get big.



Advice, Bugs, Things To Avoid, etc.

(1) You will by now have noticed that when you drop a line of script on the Morphic "desktop", it sprouts a "scriptor" around itself, ready for editing and running. This is often what you want, but when it gets annoying, which is to say, when you find you'd like to be able to drop naked lines of script and have them stay as naked lines of script, for later use, you can drop them into any "Playfield" (PasteUpMorph) rather than onto the World desktop, and you can avoid this sprouting. (Whether or not a Playfield automatically expands a dropped phrase into a complete Scriptor is governed by the "automatic phrase expansion" option, which will be found in the its "playfield options" menu.)


(2) A nice standard kind of script for lots of experimentation is: star forward by 10 "move forward ten units" star bounce silence "if hit wall of container, bounce silently"


(3) Scripts that are "ticking" provide a "live" feel, making experimentation quite easy.


(4) Be sure to try out use of the "pen" for laying down color trails. The "colorUnder" and "colorSees" tiles provide ways that objects can easily interact with their surroundings.


(5) The "conditional" in the tile-scripting system is the "Test/Yes/No" complex (your basic if/then/else); in the test pane go boolean-valued things; into the Yes and No panes go any sequence of commands.

(6) When an object is scripted to handle the mouse, you won't be able to drag it with the mouse. To drag such an object, bring up its halo, and drag it from its black-dot or brown-dot handle.


(7) At present, there is no protection against script cycles, so that you can get yourself in trouble with two scripts or more scripts that end up calling each other.


(8) Before trying to duplicate a scripted object, make sure that all its scripts are "saved and named", so that the duplicate you make will have the same scripts.



Next Steps

This User-Scripting regime is still in its infancy, as is the documentation about how to use it. We put it out at this time only in hope that some users will find something of interest in spite of the rough state of the design and the code (and in spite of the numerous temporary perturbations it has caused to an otherwise elegant Morphic graphics system.)

Coming in the foreseeable future are extensions of the user-scripting design to cover "aliases", "collections", the "stack/card" dichotomy, file-based factoring of content, Finder-like analogies for content, integration with projects, navigation morphs, integration with the more generic Morphc inspector and browser tools, and more.



Much of this design space has been explored in various earlier prototypes we've worked on, so we're not starting from ground zero, but there is plenty of architectural work still to be done before we emerge with a clean and minimal design that will extend user scripting to span the space of the "multimedia, hypermedia, and simulation tool" that we believe it may become.



Many changes are on the way. We warmly welcome participation by the Squeak community as we pursue this work, which is quite at right angles to the traditional course of Smalltalk. Just, please, don't at this stage count on user-scripting to be compact, reliable, consistent, transportable, or stable. If you can thrive on such slippery ice, please join us now! Otherwise, give it a chance to mature over the coming months.


Brainstorming and Engineering
-------------------------------------
The Squeak team works in periods of expansion, when we try new approaches and write lots of new code, and periods of reflection, where we re-factor, clean up and document (well... sometimes ;-).  It is important for critics to understand that the morphic system and the end-user programming systems that are embedded in it, are still in an expanding brainstorming phase.  We know that the clean morphic protocols have become a huge, confusing hodge-podge.

But this is important.  Morphic is being taken in new directions, including flexing, scripting, and viewing.  When we have gained experience with these new areas, when we have learned from working with some real users, then we will better understand the real kernel of this architecture, and we can return to clean it all up and cast it clearly in the metaphor that we don't fully understand right now.


Source Code Updates
------------------------
Tired of waiting months for the next release?

Now you can get code updates automatically loaded into any Squeak attached to the internet.  Choose 'update code from server' in the 'help...' menu.  (Wait, or have a Transcript open to watch the progress.)  The Squeak team will be putting approved changes to Squeak on two servers, at UIUC and at WebPage.com.  Updates are numbered and are loaded in order.

We've been using Updates in our group at Disney for six months and it has really improved our productivity.  If you want to set up your own Update server for your own organization, please contact Ted Kaehler.  It is an easy way to distribute changes to a group of people who all use Squeak.


Image Size
--------------
We have intentionally included more features with the Squeak 2.2 release than most people will use.  If space is of concern, many of these facilities can be removed to produce a considerably smaller image.

We are in the process of sanitizing and automating this removal process.  Right now, you can execute the following to achieve the approximate savings given...
	Smalltalk discardVMConstruction.  "663k"
	Smalltalk discardSoundSynthesis.  "330k"
	Smalltalk discardOddsAndEnds.  "228k"
	Smalltalk discardNetworking.  "261k"
	Smalltalk discardMorphic.  "2,231k"
The above altogether saves around 3.5 megabytes.  Executing
	Smalltalk majorShrink
will do all the above and more and should yield a final image size of around 800k.  There will be loose ends in that image that may cause errors when you attempt to use facilities that have been removed, but this is usually not fatal.  We will be updating the various shrinking routines to improve this process, and they can be browsed in the 'shrinking' category of SystemDictionary.

Want to squeeze Squeak into a PDA?  After executing the above shrinking routines, you can go on to execute
	Smalltalk abandonSources.
This will compile method temp names into a compact trailer on every method, allowing the entire system to be browsed by decompiling with temp names preserved.  This means there is no need to store the sources file on a very small machine.  While comments are not available in system code after abandoning sources, all the code you write will be preserved properly in the changes file, so that you can upload it to a full Squeak when you return from your backpack trip.


The Wiki Wiki Server
-------------------------
Swiki -- A Server of Web Pages That Any User Can Modify

Version 2 of Squeak includes a complete editable web server.  Every web page on a Swiki web site has a button that says, "Edit this Page".  It gives you the contents of the the page in a scrolling window.  When you change it and "Save", the page is instantly changed.  The user can work from any web browser.  Changing a page is so easy enough that a workgroup or class will quickly create an evolving spiderwork of their own pages.

To start your own Swiki, see the instructions in (PWS class howToStart), and get a folder with necessary template files from...
  http://www.cc.gatech.edu/fac/mark.guzdial/squeak/pws/  

Thanks to Mark Guzdial, Georg Gollmann, and Mark's students, and to the father of WikiWiki, Ward Cunningham.


Stylized Text and Links in Source Code
--------------------------------------------
Remember the discussion after OOPSLA about better documentation and navigation?  Thanks to the work of Ted Kaehler, this version of Squeak allows creation of hyperlinks in text, and preserves them (and most text styles) in source code and class comments!  This makes it possible to document Squeak more effectively than before, as you will see from the limited examples in the Sample Documentation window.  Links can be created using CMD-6, and they can deactivated by selecting (with an extra leading character, or from back to front) and using CMD-0.  Here is an example link: Text.

We hope over the next month or two to rewrite all class comments to take advantage of this new capability and establish a real "backbone" to Squeak's on-line documentation.  You will notice a new switch in the browser, suggested by Scott Wallace, that facilitates access to class comments for just this reason.

If you never put links or emphasis in your source code, everything should work just as before.  FileOuts may include style information after each method.  If you need to bring a new fileOut into an older system, read the file 'readFileinsWithStyle.cs' into your older system first.