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
#aboutToLeaveWorld
in the actionMap which causes an error message to appear when leaving the project.
Executing
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
?
--Hannes
On 10/13/17, H. Hirzel hannes.hirzel@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@freudenbergs.de wrote:
On Sat, Oct 7, 2017 at 2:17 AM, David T. Lewis lewis@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 -