[squeak-dev] MorphicProject subclass: #EtoysProject

H. Hirzel hannes.hirzel at gmail.com
Sat Oct 14 10:21:09 UTC 2017

Thank you Dave for reviewing and merging and committing Morphic-hjh.1349.mcz.

One of the next issues is that the loaded Etoys project has a key


in the actionMap which causes an error message to  appear when leaving
the project.


     Project current world actionMap removeKey: #aboutToLeaveWorld

or just

    self world actionMap removeKey: #aboutToLeaveWorld

if not called from a workspace

solves that problem.

But I am not sure if this is the right thing to do and where to put this.

The event mechanism is not used much in Squeak6.0a.  (see thread:
'PasteUpMorph>>#removeModalWindow has been deprecated --- what do we
need to do?', in particular answer by Bob Arning')

Another issue is that

      SugarNavigatorBar showSugarNavigator: true.

needs to be called.

A third question: In which directory should the three projects to preload stay?
( Section 3 on http://wiki.squeak.org/squeak/6531)

    Smalltalk imagePath



On 10/13/17, H. Hirzel <hannes.hirzel at gmail.com> wrote:
> Thank you Bert for the links to the regular three projects (home,
> gallery, tutorials) and the background information.
> Update
> -----------
> for the most recent trunk image Squeak6.0a-17417 with
> Morphic-hjh.1349.mcz loaded manually from the inbox:
> https://freudenbergs.de/bert/squeakjs/Etoys/Home.007.pr
> loads, and works but brings up an error window regarding a #script1.
> The car is moving around.
> To leave the project you need to open a workspace and paste and execute
>      Project current world actionMap removeKey: #aboutToLeaveWorld
> The menu entry 'previous project' works fine.
> - Hannes -
> On 10/10/17, Bert Freudenberg <bert at freudenbergs.de> wrote:
>> On Sat, Oct 7, 2017 at 2:17 AM, David T. Lewis <lewis at mail.msen.com>
>> wrote:
>>> On Fri, Oct 06, 2017 at 03:48:56PM +0200, Bert Freudenberg wrote:
>>> > It's all class-based. E.g. if the shape of a class changed (new /
>>> > renamed
>>> > inst vars) that class can provide a "conversion method" that creates
>>> > an
>>> > instance with the new layout from the old inst vars (that are loaded
>>> > as
>>> > a
>>> > dictionary). There still is a preference (conversionMethodsAtFileOut)
>>> that
>>> > used to prompt people to provide these conversion methods when they
>>> changed
>>> > a class. But it didn't survive the transition to Monticello, we now
>>> > have
>>> to
>>> > remember to write conversion methods for instances that may be stored
>>> > in
>>> a
>>> > project.
>>> To check my understanding, the "conversion method" might be something
>>> like
>>> #storeDataOn: and #readDataFrom:size: like what I described for
>>> DateAndTime,
>>> is that right?
>> ​No, it's those weirdly-named methods like Hannes just made
>> in Morphic-hjh.1349.mcz. The store / read methods aren't used per-object.
>> This
>> would have been too expensive back in the interpreter days on slow CPUs,
>> that's why the project is stored as an image-segment, and the segment is
>> written to a SmartRefStream with its out-pointers (references to objects
>> outside the segment, e.g. classes).
>> The SmartRefStream is only used to resolve the class references from the
>> ImageSegment that stores the project.
>>> This is different from the Etoys home screen (the clouds and
>>> drive-a-car)
>>> > which is simply a project that would be loaded by the deployment
>>> > script
>>> > that creates an Etoys image. It does not have to ship with the general
>>> > Squeak image.
>>> I do not know if it will make sense, but I guess my mental image is an
>>> Etoys "deployed image" hosted inside my regular Squeak trunk image. So I
>>> guess that I am thinking of the "clouds and drive-a-car" project being
>>> loaded the first time that I create a new EtoysProject from normal
>>> Squeak,
>>> and that somehow the subsequent project navigation within that new
>>> "hosted"
>>> Etoys would behave is if I were in a stand-alone Etoys image. Finally,
>>> I would want to be able to escape back to my normal Squeak.
>> ​That sounds good :)
>> - Bert -​

More information about the Squeak-dev mailing list