goran at krampe.se wrote:
> Kendall Shaw <queshaw at pacbell.net> wrote:
> There are numerous ways to deliver squeak "apps" or code. Project files
> are used primarily for eToys or "demos" of code.
> Most projects in the Squeak community are delivered in source form
> instead, using a variety of file formats:
> 
> 	.st (or .st.gz compressed) - the good old fileout of code. Not used
> much anymore.
> 	.cs (or .cs.gz compressed) - changesets. They are like patches from the
> regular world, quite nifty but can be confusing.
> 	.mcz - Monticello package. This is the "standard" today and is what
> most people use. The file is a zip file with source in it, in a special
> format to be loaded by Monticello.
> 	.sar - This is also a zip file with a code snippet inside for
> performing the install of the rest of the contents. .mcz files only
> contain code so a .sar file can be used as a wrapper in order to include
> other kinds of files too.

Thanks. This and your other suggestions seem to be about how to package 
an application. But, what I don't get is how you make something that 
does something, aside from by a Project.

For example, with C there is a "main" routine that is the entry point, 
so that when you have a C program you "run" it, in one uniform way for 
all programs (more or less) that causes it to "execute".

Is there something like that, in these other packaging schemes? Some 
standard instantiation interface that gets invoked to run your app? Or 
does the user have to know for each class to open a workspace and type in:

Blah something: blah somethingElse: blah.

The Project seems to do something like that, because you could have some 
GUI thing open that the user will see. Is there another similar mechanism?