Kendall Shaw wrote:
> 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".

Here lies the error :)
There is a major difference between Squeak and C regarding the
context in which code is executed. In C your program is responsible
for rebuilding your "world" every time it is run (allocate new
objects, initialization etc.) The operating system is responsible
for running the executable file in a new process so there must be a
convention about the entry point in the executable (the main(...)
function for C compilers)

In Squeak you always have your own world (the loaded image) with
Classes, Object instances etc. you are working in. If you load a
.st,.cs,.mcz then you end up with some more Classes in the image.
Later you can instantiate this classes and eventually send some
message to the instances. There is no convention of what is the
entry point like there is in C (there is no need for it :) ). Most
of the time there is a comment in the package telling you how to
make use of it.

Projects (and saving loading them from file) add a little bit more.
When you load a project you also add some new objects (instances) to
your image besides new Classes. This is way your project appears to
you in the same state as it was when the owner has saved it (some
windows already opened etc) and you can start 'clicking' around.

Think of it like a table full of toys. Someone puts a new toy on it.
You can start playing with it any way you like but don't expect all
of them to come in the same shape.

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