Well, consistency is great--sometimes!

In this case, I think the asymmetries are intentional. In the
case of the SoundPlayer, I know that's the case. The SoundPlayer
gets started any time you play a sound. If you don't play a sound,
you never need to start it at all. It is also stopped whenever
you hit the interrupt key, incidentally--a handy way to stop
a runaway sound.

	-- John

>It seems to be a bad idea to have two separate lists StartUpList,
>ShutDownList for closing and reopening the image. This invites problems:
>
>SoundPlayer - stops on save doesnt start again
>  Solution: add it to StartUpList
>  I havent tried this.
>PWS - Stops on ShutDown, doesnt start on StartUp.
>  Solution: add it to StartUpList. (In SystemDictionary
>class>>initialize)
>  This I have tried, see manual ChangeSet below. The PWS will then
>continue to run until stopped. Try starting it, save and quit, restart,
>it will run again.
>
>There is obviously a general pattern here, whatever is frosen on
>shutdown should be thawed on startup.
>
>Better to have one list. It could be called FreezeList for instance.
>Send startUp in order at startup, send shutDown in reverse order at
>shutdown. The default will then be that things continue to work
>transcending save/restore.
>
>Questions:
>
>Why is this initialized within SystemDictionary not in
>aClass>>initialize?
>
>Why is this restricted to classes? Why not give any object that wants it
>shutDown/startUp messages?
>
>/Mats Nygren
>
>--  ChangeSet (kind of)  --
>
>"
>SystemDictionary class>>initialize
>add:
>	Smalltalk addToStartUpList: PWS.
>before:
>	Smalltalk addToStartUpList: ImageSegment.
>"
>
>'From Squeak2.8alpha of 12 May 2000 [latest update: #2158] on 1 June
>2000 at 3:56:00 pm'!
>
>!PWS class methodsFor: 'Serving' stamp: 'mn 5/18/2000 17:35'!
>startUp
>   "PWS startUp"
>	"rewrite howTOStart a little"
>	"of course 8080 and log.txt should be changed to the actual values"
>   PWS serveOnPort: 8080 loggingTo: 'log.txt'
>! !