+1 :)

And then later: Rename PasteUpMorph to WorldMorph, and keep an empty PasteUpMorph subclass around for compatibility reasons. So many ideas have been ported down to Morph class over the past years. New applications have no reason to ever use other instances of PasteUpMorph.

Best, Marcel Am 03.10.2017 14:57:55 schrieb H. Hirzel hannes.hirzel@gmail.com: On 10/3/17, H. Hirzel wrote:

Dave

your change set contains the class EtoysProject with

EtoysProject selectors

#(#finalEnterActions: #restoreGlobalPreferences #saveGlobalPreferences #initializeProjectPreferences #configureOnFirstEntry #finalExitActions:)

For complete configuration of a EtoysProject it might be necessary to do

PasteUpMorph subclass: EtoysPasteUpMorph

as well. http://wiki.squeak.org/squeak/6461

Then Etoys related methods may be pushed down to EtoysPasteUpMorph.

See screen shot attached.

And probably an Etoys specific subclass of WorldMenu would be fine as well http://wiki.squeak.org/squeak/6461

there is a test project [2] and some more information about adaptions needed because of the UI changes in the thread 'Etoys in 2017?' - UI preferences [3]. And it would be good to have Etoys methods / configuration separate [4].

I suggest that you start go ahead and start implementing this while using a test Etoys project dropped onto the desktop.

--Hannes

[2] > You simply drop it in. E.g. download this project

...

http://etoys.laptop.org/src/Content/ExampleEtoys/CarAndPen.014.pr

[3] Hannes Hirzel, 'Etoys in 2017?' mail, Wed, Feb 22, 2017 at 11:01 AM

[4] David T. Lewis, Sep 4, 2016 at 3:34 PM "I think it would be great if both Etoys and Scratch were easily loadable and unloadable in trunk."

On 10/2/17, David T. Lewis wrote:

...

An EtoysProject is a project that is configured for running Etoys. On first entry to a new EtoysProject, the playground and project preferences are initialized to provide an environment similar to that of a traditional standalone Etoys image.

Certain preferences that are required for Etoys are initialized on project entry, overriding their global preference values while this EtoysProject is active. On leaving the project, these preferences are restored to their previous values.

"ProjectViewMorph openOn: EtoysProject new"

Change set attached for a minimal implementation.

Anyone with Etoys knowledge care to help? I do not know enough about Etoys to fill in the rest of the initialization that will be required, but it should not be hard to do.

Dave

On 10/3/17, Tobias Pape Das.Linux@gmx.de wrote:

...

On 03.10.2017, at 15:03, Marcel Taeumel marcel.taeumel@hpi.de wrote:

+1 :)

And then later: Rename PasteUpMorph to WorldMorph, and keep an empty PasteUpMorph subclass around for compatibility reasons. So many ideas have been ported down to Morph class over the past years. New applications have no reason to ever use other instances of PasteUpMorph.

-1 Except for Background images, gridding, drag-and-drop helpers, etc. It should rather be a PlayField (as it comment already states).

PlayField? I do not find a class named 'PlayField' in a current Trunk image. Which class do you mean?

Also, be wary of the "rename then subclass" deprecation, because if certain projects extend the deprecated subclass (And a lot do for PasteUpMorph), those extensions will never be used in typical circumstances.

(This also bit me with the ContextPart depercation… Certain tools that hook into debugging stuff via ContextPart extensions no longer work as no ContextParts will ever be around. Oh well..)

Best regards -Tobias

...

Best, Marcel

...

Am 03.10.2017 14:57:55 schrieb H. Hirzel hannes.hirzel@gmail.com:

On 10/3/17, H. Hirzel wrote:

...

Dave

your change set contains the class EtoysProject with

EtoysProject selectors

#(#finalEnterActions: #restoreGlobalPreferences #saveGlobalPreferences #initializeProjectPreferences #configureOnFirstEntry #finalExitActions:)

For complete configuration of a EtoysProject it might be necessary to do

PasteUpMorph subclass: EtoysPasteUpMorph

as well. http://wiki.squeak.org/squeak/6461

Then Etoys related methods may be pushed down to EtoysPasteUpMorph.

See screen shot attached.

...

And probably an Etoys specific subclass of WorldMenu would be fine as well http://wiki.squeak.org/squeak/6461

there is a test project [2] and some more information about adaptions needed because of the UI changes in the thread 'Etoys in 2017?' - UI preferences [3]. And it would be good to have Etoys methods / configuration separate [4].

I suggest that you start go ahead and start implementing this while using a test Etoys project dropped onto the desktop.

--Hannes

[2] > You simply drop it in. E.g. download this project

...

http://etoys.laptop.org/src/Content/ExampleEtoys/CarAndPen.014.pr

[3] Hannes Hirzel, 'Etoys in 2017?' mail, Wed, Feb 22, 2017 at 11:01 AM

[4] David T. Lewis, Sep 4, 2016 at 3:34 PM "I think it would be great if both Etoys and Scratch were easily loadable and unloadable in trunk."

On 10/2/17, David T. Lewis wrote:

...

An EtoysProject is a project that is configured for running Etoys. On first entry to a new EtoysProject, the playground and project preferences are initialized to provide an environment similar to that of a traditional standalone Etoys image.

Certain preferences that are required for Etoys are initialized on project entry, overriding their global preference values while this EtoysProject is active. On leaving the project, these preferences are restored to their previous values.

"ProjectViewMorph openOn: EtoysProject new"

Change set attached for a minimal implementation.

Anyone with Etoys knowledge care to help? I do not know enough about Etoys to fill in the rest of the initialization that will be required, but it should not be hard to do.

Dave

@Tobias: In the future, we should get the project-specific parts of PasteUpMorph extracted into sth. called WorldMorph to be used only as the global "desktop thingy" for Morphic projects. The currently mixed state is really confusing. If there is other left-over stuff not yet ready for the Morph base class (gridding?), we could add an additional "Playfield", too. Not sure about the name, though. :)

I do not think that it is worth supporting existing code that relies on "PasteUpMorph allInstances" to work in its current form. Same for "ContextPart allInstances".

Best, Marcel Am 03.10.2017 15:34:25 schrieb H. Hirzel hannes.hirzel@gmail.com: What Marcel refers to

Morph BorderedMorph PasteUpMorph "maintains the current tasks of Background images, gridding, drag-and-drop helpers" EtoysMorph "keeps Etoys specific messages"

And then

Morph BorderedMorph WorldMorph (PasteUpMorph renamed, methods such as gridding maintained) PasteUpMorph "empty PasteUpMorph class for compatibility" EtoysPasteUpMorph "keeps Etoys specific messages"

Another issue not discussed here is that PasteUpMorph includes WorldMorph functions.

Pharo has separated this. This is an issue which comes up from time to time. [5] The advantage of keeping them together is that you may have worlds in worlds. But this discussion is not related to the issue Etoys refactoring issue.

--Hannes

[5] http://forum.world.st/WorldMorph-subclass-PasteUpMorph-tp4946461p4946465.htm...

On 10/3/17, H. Hirzel wrote:

On 10/3/17, Tobias Pape wrote:

...

...

On 03.10.2017, at 15:03, Marcel Taeumel wrote:

+1 :)

And then later: Rename PasteUpMorph to WorldMorph, and keep an empty PasteUpMorph subclass around for compatibility reasons. So many ideas have been ported down to Morph class over the past years. New applications have no reason to ever use other instances of PasteUpMorph.

-1 Except for Background images, gridding, drag-and-drop helpers, etc. It should rather be a PlayField (as it comment already states).

PlayField? I do not find a class named 'PlayField' in a current Trunk image. Which class do you mean?

...

Also, be wary of the "rename then subclass" deprecation, because if certain projects extend the deprecated subclass (And a lot do for PasteUpMorph), those extensions will never be used in typical circumstances.

(This also bit me with the ContextPart depercation… Certain tools that hook into debugging stuff via ContextPart extensions no longer work as no ContextParts will ever be around. Oh well..)

Best regards -Tobias

...

Best, Marcel

...

Am 03.10.2017 14:57:55 schrieb H. Hirzel :

On 10/3/17, H. Hirzel wrote:

...

Dave

your change set contains the class EtoysProject with

EtoysProject selectors

#(#finalEnterActions: #restoreGlobalPreferences #saveGlobalPreferences #initializeProjectPreferences #configureOnFirstEntry #finalExitActions:)

For complete configuration of a EtoysProject it might be necessary to do

PasteUpMorph subclass: EtoysPasteUpMorph

as well. http://wiki.squeak.org/squeak/6461

Then Etoys related methods may be pushed down to EtoysPasteUpMorph.

See screen shot attached.

...

And probably an Etoys specific subclass of WorldMenu would be fine as well http://wiki.squeak.org/squeak/6461

there is a test project [2] and some more information about adaptions needed because of the UI changes in the thread 'Etoys in 2017?' - UI preferences [3]. And it would be good to have Etoys methods / configuration separate [4].

I suggest that you start go ahead and start implementing this while using a test Etoys project dropped onto the desktop.

--Hannes

[2] > You simply drop it in. E.g. download this project

...

http://etoys.laptop.org/src/Content/ExampleEtoys/CarAndPen.014.pr

[3] Hannes Hirzel, 'Etoys in 2017?' mail, Wed, Feb 22, 2017 at 11:01 AM

[4] David T. Lewis, Sep 4, 2016 at 3:34 PM "I think it would be great if both Etoys and Scratch were easily loadable and unloadable in trunk."

On 10/2/17, David T. Lewis wrote:

...

An EtoysProject is a project that is configured for running Etoys. On first entry to a new EtoysProject, the playground and project preferences are initialized to provide an environment similar to that of a traditional standalone Etoys image.

Certain preferences that are required for Etoys are initialized on project entry, overriding their global preference values while this EtoysProject is active. On leaving the project, these preferences are restored to their previous values.

"ProjectViewMorph openOn: EtoysProject new"

Change set attached for a minimal implementation.

Anyone with Etoys knowledge care to help? I do not know enough about Etoys to fill in the rest of the initialization that will be required, but it should not be hard to do.

Dave

Attached is screen shot which shows over 3000 'empty' MorphicModel subclasses illustrating the need to have a

'slide' or 'page' class

with just 'gridding' and 'drag and drop' behaviour. Probably just above what is currently called 'PasteUpMorph'. It would then contain gridding and drag and drop behaviour shifted up from PasteUpMorph.

On 10/3/17, H. Hirzel hannes.hirzel@gmail.com wrote:

On 10/3/17, Marcel Taeumel marcel.taeumel@hpi.de wrote:

...

@Tobias: In the future, we should get the project-specific parts of PasteUpMorph extracted into sth. called WorldMorph to be used only as the global "desktop thingy" for Morphic projects. The currently mixed state is really confusing. If there is other left-over stuff not yet ready for the Morph base class (gridding?), we could add an additional "Playfield", too. Not sure about the name, though. :)

Yes, I am fine with this.

A comparatively "deep" hierarchy of classes is not a problem as there are many methods and grouping the different tasks into different classes (each one a subclass of the other) will help to understand and maintain the code.

The current PasteUpMorph has a lot of Etoys related functions (Player related). Just to keep morphs on "slide" or "page" needs a lot less code.

In an image I mainly used during a year I had

PasteUpMorph allInstances size 1721

and MorphicModel allSubclasses size 3581 (unused subclasses as the PasteUpMorph morphs were just used to paste morphs on it. No active content)

(Note that the SystemBrowser does not show MorphicModel subclasses)

...

I do not think that it is worth supporting existing code that relies on "PasteUpMorph allInstances" to work in its current form. Same for "ContextPart allInstances".

Best, Marcel Am 03.10.2017 15:34:25 schrieb H. Hirzel hannes.hirzel@gmail.com: What Marcel refers to

Morph BorderedMorph PasteUpMorph "maintains the current tasks of Background images, gridding, drag-and-drop helpers" EtoysMorph "keeps Etoys specific messages"

And then

Morph BorderedMorph WorldMorph (PasteUpMorph renamed, methods such as gridding maintained) PasteUpMorph "empty PasteUpMorph class for compatibility" EtoysPasteUpMorph "keeps Etoys specific messages"

Another issue not discussed here is that PasteUpMorph includes WorldMorph functions.

Pharo has separated this. This is an issue which comes up from time to time. [5] The advantage of keeping them together is that you may have worlds in worlds. But this discussion is not related to the issue Etoys refactoring issue.

--Hannes

[5] http://forum.world.st/WorldMorph-subclass-PasteUpMorph-tp4946461p4946465.htm...

On 10/3/17, H. Hirzel wrote:

...

On 10/3/17, Tobias Pape wrote:

...

...

On 03.10.2017, at 15:03, Marcel Taeumel wrote:

+1 :)

And then later: Rename PasteUpMorph to WorldMorph, and keep an empty PasteUpMorph subclass around for compatibility reasons. So many ideas have been ported down to Morph class over the past years. New applications have no reason to ever use other instances of PasteUpMorph.

-1 Except for Background images, gridding, drag-and-drop helpers, etc. It should rather be a PlayField (as it comment already states).

PlayField? I do not find a class named 'PlayField' in a current Trunk image. Which class do you mean?

...

Also, be wary of the "rename then subclass" deprecation, because if certain projects extend the deprecated subclass (And a lot do for PasteUpMorph), those extensions will never be used in typical circumstances.

(This also bit me with the ContextPart depercation… Certain tools that hook into debugging stuff via ContextPart extensions no longer work as no ContextParts will ever be around. Oh well..)

Best regards -Tobias

...

Best, Marcel

...

Am 03.10.2017 14:57:55 schrieb H. Hirzel :

On 10/3/17, H. Hirzel wrote: > Dave > > your change set contains the class EtoysProject with > > EtoysProject selectors > > #(#finalEnterActions: #restoreGlobalPreferences > #saveGlobalPreferences > #initializeProjectPreferences #configureOnFirstEntry > #finalExitActions:) > > For complete configuration of a EtoysProject it might be necessary > to > do > > PasteUpMorph subclass: EtoysPasteUpMorph > > as well. http://wiki.squeak.org/squeak/6461 > > Then Etoys related methods may be pushed down to EtoysPasteUpMorph.

See screen shot attached.

> And probably an Etoys specific subclass of WorldMenu would be fine > as > well > http://wiki.squeak.org/squeak/6461 > > > there is a test project [2] and some more information about > adaptions > needed because of the UI changes in the thread 'Etoys in 2017?' - > UI > preferences [3]. And it would be good to have Etoys methods / > configuration separate [4]. > > I suggest that you start go ahead and start implementing this while > using a test Etoys project dropped onto the desktop. > > --Hannes > > > [2] > You simply drop it in. E.g. download this project >> http://etoys.laptop.org/src/Content/ExampleEtoys/CarAndPen.014.pr > > [3] Hannes Hirzel, 'Etoys in 2017?' mail, Wed, Feb 22, 2017 at > 11:01 > AM > > > [4] David T. Lewis, Sep 4, 2016 at 3:34 PM > "I think it would be great if both Etoys and Scratch were easily > loadable and unloadable in trunk." > > On 10/2/17, David T. Lewis wrote: >> An EtoysProject is a project that is configured for running Etoys. >> On >> first entry to a new EtoysProject, the playground and project >> preferences >> are initialized to provide an environment similar to that of a >> traditional >> standalone Etoys image. >> >> Certain preferences that are required for Etoys are initialized on >> project >> entry, overriding their global preference values while this >> EtoysProject >> is active. On leaving the project, these preferences are restored >> to >> their >> previous values. >> >> "ProjectViewMorph openOn: EtoysProject new" >> >> Change set attached for a minimal implementation. >> >> Anyone with Etoys knowledge care to help? I do not know enough >> about >> Etoys >> to fill in the rest of the initialization that will be required, >> but >> it >> should not be hard to do. >> >> Dave >> >> >

Thank you for the clarification, Tobias.

As noted earlier in the thread the suggestion at the moment is just to subclass

PasteUpMorph subclass: EtoysPasteUpMorph

and push all the *Etoys related methods down to EtoysPasteUpMorph.

Link to from EtoysProject to EtoysPasteUpMorph can easily be done in the initialize method of EtoysProject

MorphicProject initialize "Initialize a new Morphic Project" super initialize. world := PasteUpMorph newWorldForProject: self. self setWorldBackground: true. Locale switchToID: CurrentProject localeID. Preferences useVectorVocabulary ifTrue: [world installVectorVocabulary]

EtoysProject initialize "Initialize a new Morphic Project" super initialize. world := EtoysPasteUpMorph newWorldForProject: self. self setWorldBackground: true. Locale switchToID: CurrentProject localeID. Preferences useVectorVocabulary ifTrue: [world installVectorVocabulary]

or maybe better not override the initialize method but asking the class in MorphicProject

MorphicProject initialize "Initialize a new Morphic Project" super initialize. world := self class defaultPasteUpMorphClass newWorldForProject: self. self setWorldBackground: true. Locale switchToID: CurrentProject localeID. Preferences useVectorVocabulary ifTrue: [world installVectorVocabulary]

It depends on other issue which have to be done in

EtoysProject initialize

On 10/3/17, Tobias Pape Das.Linux@gmx.de wrote:

...

On 03.10.2017, at 15:17, H. Hirzel hannes.hirzel@gmail.com wrote:

On 10/3/17, Tobias Pape Das.Linux@gmx.de wrote:

...

...

On 03.10.2017, at 15:03, Marcel Taeumel marcel.taeumel@hpi.de wrote:

+1 :)

And then later: Rename PasteUpMorph to WorldMorph, and keep an empty PasteUpMorph subclass around for compatibility reasons. So many ideas have been ported down to Morph class over the past years. New applications have no reason to ever use other instances of PasteUpMorph.

-1 Except for Background images, gridding, drag-and-drop helpers, etc. It should rather be a PlayField (as it comment already states).

...

PlayField? I do not find a class named 'PlayField' in a current Trunk image. Which class do you mean?

Comment of PasteUpMorph:

"A morph whose submorphs comprise a paste-up of rectangular subparts which "show through". Anything called a 'Playfield' is a PasteUpMorph."

etc.

Best regards -Tobias

...

...

Also, be wary of the "rename then subclass" deprecation, because if certain projects extend the deprecated subclass (And a lot do for PasteUpMorph), those extensions will never be used in typical circumstances.

(This also bit me with the ContextPart depercation… Certain tools that hook into debugging stuff via ContextPart extensions no longer work as no ContextParts will ever be around. Oh well..)

Best regards -Tobias

...

Best, Marcel

...

Am 03.10.2017 14:57:55 schrieb H. Hirzel hannes.hirzel@gmail.com:

On 10/3/17, H. Hirzel wrote:

...

Dave

your change set contains the class EtoysProject with

EtoysProject selectors

#(#finalEnterActions: #restoreGlobalPreferences #saveGlobalPreferences #initializeProjectPreferences #configureOnFirstEntry #finalExitActions:)

For complete configuration of a EtoysProject it might be necessary to do

PasteUpMorph subclass: EtoysPasteUpMorph

as well. http://wiki.squeak.org/squeak/6461

Then Etoys related methods may be pushed down to EtoysPasteUpMorph.

See screen shot attached.

...

And probably an Etoys specific subclass of WorldMenu would be fine as well http://wiki.squeak.org/squeak/6461

there is a test project [2] and some more information about adaptions needed because of the UI changes in the thread 'Etoys in 2017?' - UI preferences [3]. And it would be good to have Etoys methods / configuration separate [4].

I suggest that you start go ahead and start implementing this while using a test Etoys project dropped onto the desktop.

--Hannes

[2] > You simply drop it in. E.g. download this project > http://etoys.laptop.org/src/Content/ExampleEtoys/CarAndPen.014.pr

[3] Hannes Hirzel, 'Etoys in 2017?' mail, Wed, Feb 22, 2017 at 11:01 AM

[4] David T. Lewis, Sep 4, 2016 at 3:34 PM "I think it would be great if both Etoys and Scratch were easily loadable and unloadable in trunk."

On 10/2/17, David T. Lewis wrote: > An EtoysProject is a project that is configured for running Etoys. On > first entry to a new EtoysProject, the playground and project > preferences > are initialized to provide an environment similar to that of a > traditional > standalone Etoys image. > > Certain preferences that are required for Etoys are initialized on > project > entry, overriding their global preference values while this > EtoysProject > is active. On leaving the project, these preferences are restored to > their > previous values. > > "ProjectViewMorph openOn: EtoysProject new" > > Change set attached for a minimal implementation. > > Anyone with Etoys knowledge care to help? I do not know enough about > Etoys > to fill in the rest of the initialization that will be required, but > it > should not be hard to do. > > Dave > >

Hi Dave,

I just added an account "mt2" ... because "mt" was already taken. :)

Best, Marcel Am 04.10.2017 03:29:07 schrieb David T. Lewis lewis@mail.msen.com: I put my initial change set on SqueakSource at http://www.squeaksource.com/EtoysProject.

This is intended as a temporary SqueakSource project for working out how to structure EtoysProject and get it to open a new project with the familiar playfield.

Hannes, Tobias, Bert and I have write access, and I would like to add Marcel if he has a squeaksource.com account (I could not find it). Please commit anything that you thimk makes sense.

As you may have guessed by now, I do not actually know enough about Etoys to make it work. I just put that change set out to see if I could Tom Sawyer a few of the more knowledgable folks to doing the hard parts. I think it might be working :-)

I think that the Etoys package in trunk is probably too large for us to be doing a lot of experimental changes right now, so my hope is that by putting the Project related part into its own package temporarily, and putting that up on squeaksource.com, that we can get this part working well enough to merge back into Etoys in trunk when it is ready.

From my point of view, "working well enough" means:

- Open a new EtoysProject in Trunk, and the result is an Etoys playfield that is reasonably similar to a stand-alone Etoys image. The new project should open with the little car driving around, and with tabs and menus as expected for Etoys.

- Returning from that Etoys project brings you back to a project that still works. Whatever preferences were established or overridden to make Etoys work should be restored so that the other projects are not affected.

Dave

On Tue, Oct 03, 2017 at 10:45:12PM +0200, H. Hirzel wrote:

Thank you for the clarification, Tobias.

As noted earlier in the thread the suggestion at the moment is just to subclass

PasteUpMorph subclass: EtoysPasteUpMorph

and push all the *Etoys related methods down to EtoysPasteUpMorph.

Link to from EtoysProject to EtoysPasteUpMorph can easily be done in the initialize method of EtoysProject

MorphicProject initialize "Initialize a new Morphic Project" super initialize. world := PasteUpMorph newWorldForProject: self. self setWorldBackground: true. Locale switchToID: CurrentProject localeID. Preferences useVectorVocabulary ifTrue: [world installVectorVocabulary]

EtoysProject initialize "Initialize a new Morphic Project" super initialize. world := EtoysPasteUpMorph newWorldForProject: self. self setWorldBackground: true. Locale switchToID: CurrentProject localeID. Preferences useVectorVocabulary ifTrue: [world installVectorVocabulary]

or maybe better not override the initialize method but asking the class in MorphicProject

MorphicProject initialize "Initialize a new Morphic Project" super initialize. world := self class defaultPasteUpMorphClass newWorldForProject: self. self setWorldBackground: true. Locale switchToID: CurrentProject localeID. Preferences useVectorVocabulary ifTrue: [world installVectorVocabulary]

It depends on other issue which have to be done in

EtoysProject initialize

On 10/3/17, Tobias Pape wrote:

...

...

On 03.10.2017, at 15:17, H. Hirzel wrote:

On 10/3/17, Tobias Pape wrote:

...

...

On 03.10.2017, at 15:03, Marcel Taeumel wrote:

+1 :)

And then later: Rename PasteUpMorph to WorldMorph, and keep an empty PasteUpMorph subclass around for compatibility reasons. So many ideas have been ported down to Morph class over the past years. New applications have no reason to ever use other instances of PasteUpMorph.

-1 Except for Background images, gridding, drag-and-drop helpers, etc. It should rather be a PlayField (as it comment already states).

...

PlayField? I do not find a class named 'PlayField' in a current Trunk image. Which class do you mean?

Comment of PasteUpMorph:

"A morph whose submorphs comprise a paste-up of rectangular subparts which "show through". Anything called a 'Playfield' is a PasteUpMorph."

etc.

Best regards -Tobias

...

...

Also, be wary of the "rename then subclass" deprecation, because if certain projects extend the deprecated subclass (And a lot do for PasteUpMorph), those extensions will never be used in typical circumstances.

(This also bit me with the ContextPart depercation??? Certain tools that hook into debugging stuff via ContextPart extensions no longer work as no ContextParts will ever be around. Oh well..)

Best regards -Tobias

...

Best, Marcel

...

Am 03.10.2017 14:57:55 schrieb H. Hirzel :

On 10/3/17, H. Hirzel wrote: > Dave > > your change set contains the class EtoysProject with > > EtoysProject selectors > > #(#finalEnterActions: #restoreGlobalPreferences #saveGlobalPreferences > #initializeProjectPreferences #configureOnFirstEntry > #finalExitActions:) > > For complete configuration of a EtoysProject it might be necessary to > do > > PasteUpMorph subclass: EtoysPasteUpMorph > > as well. http://wiki.squeak.org/squeak/6461 > > Then Etoys related methods may be pushed down to EtoysPasteUpMorph.

See screen shot attached.

> And probably an Etoys specific subclass of WorldMenu would be fine as > well > http://wiki.squeak.org/squeak/6461 > > > there is a test project [2] and some more information about adaptions > needed because of the UI changes in the thread 'Etoys in 2017?' - UI > preferences [3]. And it would be good to have Etoys methods / > configuration separate [4]. > > I suggest that you start go ahead and start implementing this while > using a test Etoys project dropped onto the desktop. > > --Hannes > > > [2] > You simply drop it in. E.g. download this project >> http://etoys.laptop.org/src/Content/ExampleEtoys/CarAndPen.014.pr > > [3] Hannes Hirzel, 'Etoys in 2017?' mail, Wed, Feb 22, 2017 at 11:01 > AM > > > [4] David T. Lewis, Sep 4, 2016 at 3:34 PM > "I think it would be great if both Etoys and Scratch were easily > loadable and unloadable in trunk." > > On 10/2/17, David T. Lewis wrote: >> An EtoysProject is a project that is configured for running Etoys. On >> first entry to a new EtoysProject, the playground and project >> preferences >> are initialized to provide an environment similar to that of a >> traditional >> standalone Etoys image. >> >> Certain preferences that are required for Etoys are initialized on >> project >> entry, overriding their global preference values while this >> EtoysProject >> is active. On leaving the project, these preferences are restored to >> their >> previous values. >> >> "ProjectViewMorph openOn: EtoysProject new" >> >> Change set attached for a minimal implementation. >> >> Anyone with Etoys knowledge care to help? I do not know enough about >> Etoys >> to fill in the rest of the initialization that will be required, but >> it >> should not be hard to do. >> >> Dave >> >> >

I'm not sure anybody uses Etoys anymore, but PasteUpMorph is very useful in direct manipulation because of it's various layout and event handling options. It also act as a container of other morphs, with automatic layout, enumeration etc. I'm sure most of this could be refactored into Morph class or another class.

Best, Karl

On Tue, Oct 3, 2017 at 3:03 PM, Marcel Taeumel marcel.taeumel@hpi.de wrote:

+1 :)

And then later: Rename PasteUpMorph to WorldMorph, and keep an empty PasteUpMorph subclass around for compatibility reasons. So many ideas have been ported down to Morph class over the past years. New applications have no reason to ever use other instances of PasteUpMorph.

Best, Marcel

Am 03.10.2017 14:57:55 schrieb H. Hirzel hannes.hirzel@gmail.com: On 10/3/17, H. Hirzel wrote:

...

Dave

your change set contains the class EtoysProject with

EtoysProject selectors

#(#finalEnterActions: #restoreGlobalPreferences #saveGlobalPreferences #initializeProjectPreferences #configureOnFirstEntry #finalExitActions:)

For complete configuration of a EtoysProject it might be necessary to do

PasteUpMorph subclass: EtoysPasteUpMorph

as well. http://wiki.squeak.org/squeak/6461

Then Etoys related methods may be pushed down to EtoysPasteUpMorph.

See screen shot attached.

...

And probably an Etoys specific subclass of WorldMenu would be fine as

well

...

http://wiki.squeak.org/squeak/6461

there is a test project [2] and some more information about adaptions needed because of the UI changes in the thread 'Etoys in 2017?' - UI preferences [3]. And it would be good to have Etoys methods / configuration separate [4].

I suggest that you start go ahead and start implementing this while using a test Etoys project dropped onto the desktop.

--Hannes

[2] > You simply drop it in. E.g. download this project

...

http://etoys.laptop.org/src/Content/ExampleEtoys/CarAndPen.014.pr

[3] Hannes Hirzel, 'Etoys in 2017?' mail, Wed, Feb 22, 2017 at 11:01 AM

[4] David T. Lewis, Sep 4, 2016 at 3:34 PM "I think it would be great if both Etoys and Scratch were easily loadable and unloadable in trunk."

On 10/2/17, David T. Lewis wrote:

...

An EtoysProject is a project that is configured for running Etoys. On first entry to a new EtoysProject, the playground and project

preferences

...

...

are initialized to provide an environment similar to that of a traditional standalone Etoys image.

Certain preferences that are required for Etoys are initialized on project entry, overriding their global preference values while this

EtoysProject

...

...

is active. On leaving the project, these preferences are restored to their previous values.

"ProjectViewMorph openOn: EtoysProject new"

Change set attached for a minimal implementation.

Anyone with Etoys knowledge care to help? I do not know enough about Etoys to fill in the rest of the initialization that will be required, but it should not be hard to do.

Dave

Karl,

So far entering and existing the Etoys project works smoothly.

Load mcz from into current Squeak 6.0a

MCHttpRepository location: 'http://www.squeaksource.com/EtoysProject' user: '' password: ''

The issue is about providing more settings when entering.

Karl, do you want to be added to the list of developers?

--HH

On 10/5/17, H. Hirzel hannes.hirzel@gmail.com wrote:

PasteUpMorph is useful and the functions have to be maintained.

However adding more functions to Morph does not make sense.

Squeak 6.0a Morph selectors size 1345 PasteUpMorph selectors size 530

--Hannes

On 10/4/17, karl ramberg karlramberg@gmail.com wrote:

...

I'm not sure anybody uses Etoys anymore, but PasteUpMorph is very useful in direct manipulation because of it's various layout and event handling options. It also act as a container of other morphs, with automatic layout, enumeration etc. I'm sure most of this could be refactored into Morph class or another class.

Best, Karl

On Tue, Oct 3, 2017 at 3:03 PM, Marcel Taeumel marcel.taeumel@hpi.de wrote:

...

+1 :)

And then later: Rename PasteUpMorph to WorldMorph, and keep an empty PasteUpMorph subclass around for compatibility reasons. So many ideas have been ported down to Morph class over the past years. New applications have no reason to ever use other instances of PasteUpMorph.

Best, Marcel

Am 03.10.2017 14:57:55 schrieb H. Hirzel hannes.hirzel@gmail.com: On 10/3/17, H. Hirzel wrote:

...

Dave

your change set contains the class EtoysProject with

EtoysProject selectors

#(#finalEnterActions: #restoreGlobalPreferences #saveGlobalPreferences #initializeProjectPreferences #configureOnFirstEntry #finalExitActions:)

For complete configuration of a EtoysProject it might be necessary to do

PasteUpMorph subclass: EtoysPasteUpMorph

as well. http://wiki.squeak.org/squeak/6461

Then Etoys related methods may be pushed down to EtoysPasteUpMorph.

See screen shot attached.

...

And probably an Etoys specific subclass of WorldMenu would be fine as

well

...

http://wiki.squeak.org/squeak/6461

there is a test project [2] and some more information about adaptions needed because of the UI changes in the thread 'Etoys in 2017?' - UI preferences [3]. And it would be good to have Etoys methods / configuration separate [4].

I suggest that you start go ahead and start implementing this while using a test Etoys project dropped onto the desktop.

--Hannes

[2] > You simply drop it in. E.g. download this project

...

http://etoys.laptop.org/src/Content/ExampleEtoys/CarAndPen.014.pr

[3] Hannes Hirzel, 'Etoys in 2017?' mail, Wed, Feb 22, 2017 at 11:01 AM

[4] David T. Lewis, Sep 4, 2016 at 3:34 PM "I think it would be great if both Etoys and Scratch were easily loadable and unloadable in trunk."

On 10/2/17, David T. Lewis wrote:

...

An EtoysProject is a project that is configured for running Etoys. On first entry to a new EtoysProject, the playground and project

preferences

...

...

are initialized to provide an environment similar to that of a traditional standalone Etoys image.

Certain preferences that are required for Etoys are initialized on project entry, overriding their global preference values while this

EtoysProject

...

...

is active. On leaving the project, these preferences are restored to their previous values.

"ProjectViewMorph openOn: EtoysProject new"

Change set attached for a minimal implementation.

Anyone with Etoys knowledge care to help? I do not know enough about Etoys to fill in the rest of the initialization that will be required, but it should not be hard to do.

Dave

Dave,

Yes, I encounter problems. They might be related to what I just tried to do:

I wanted to save an updated version of Morphic to the ProjectEtoys repository but by mistake I tried to commit it to the trunk. As I do not have commit rights to trunk this prevented me from changing it inadvertently. Later on I wanted to commit that version to ProjectEtoys. It did not work.

--Hannes

On 10/5/17, David T. Lewis lewis@mail.msen.com wrote:

I'm seeing problems with SqueakSource right now, trying to figure out what is wrong. So the project may not be accessible right now :-/

Dave

On Thu, Oct 05, 2017 at 01:17:58AM +0200, H. Hirzel wrote:

...

Karl,

So far entering and existing the Etoys project works smoothly.

Load mcz from into current Squeak 6.0a

MCHttpRepository location: 'http://www.squeaksource.com/EtoysProject' user: '' password: ''

The issue is about providing more settings when entering.

Karl, do you want to be added to the list of developers?

--HH

On 10/5/17, H. Hirzel hannes.hirzel@gmail.com wrote:

...

PasteUpMorph is useful and the functions have to be maintained.

However adding more functions to Morph does not make sense.

Squeak 6.0a Morph selectors size 1345 PasteUpMorph selectors size 530

--Hannes

On 10/4/17, karl ramberg karlramberg@gmail.com wrote:

...

I'm not sure anybody uses Etoys anymore, but PasteUpMorph is very useful in direct manipulation because of it's various layout and event handling options. It also act as a container of other morphs, with automatic layout, enumeration etc. I'm sure most of this could be refactored into Morph class or another class.

Best, Karl

On Tue, Oct 3, 2017 at 3:03 PM, Marcel Taeumel marcel.taeumel@hpi.de wrote:

...

+1 :)

And then later: Rename PasteUpMorph to WorldMorph, and keep an empty PasteUpMorph subclass around for compatibility reasons. So many ideas have been ported down to Morph class over the past years. New applications have no reason to ever use other instances of PasteUpMorph.

Best, Marcel

Am 03.10.2017 14:57:55 schrieb H. Hirzel hannes.hirzel@gmail.com: On 10/3/17, H. Hirzel wrote:

...

Dave

your change set contains the class EtoysProject with

EtoysProject selectors

#(#finalEnterActions: #restoreGlobalPreferences #saveGlobalPreferences #initializeProjectPreferences #configureOnFirstEntry #finalExitActions:)

For complete configuration of a EtoysProject it might be necessary to do

PasteUpMorph subclass: EtoysPasteUpMorph

as well. http://wiki.squeak.org/squeak/6461

Then Etoys related methods may be pushed down to EtoysPasteUpMorph.

See screen shot attached.

...

And probably an Etoys specific subclass of WorldMenu would be fine as

well

...

http://wiki.squeak.org/squeak/6461

there is a test project [2] and some more information about adaptions needed because of the UI changes in the thread 'Etoys in 2017?' - UI preferences [3]. And it would be good to have Etoys methods / configuration separate [4].

I suggest that you start go ahead and start implementing this while using a test Etoys project dropped onto the desktop.

--Hannes

[2] > You simply drop it in. E.g. download this project > http://etoys.laptop.org/src/Content/ExampleEtoys/CarAndPen.014.pr

[3] Hannes Hirzel, 'Etoys in 2017?' mail, Wed, Feb 22, 2017 at 11:01 AM

[4] David T. Lewis, Sep 4, 2016 at 3:34 PM "I think it would be great if both Etoys and Scratch were easily loadable and unloadable in trunk."

On 10/2/17, David T. Lewis wrote: > An EtoysProject is a project that is configured for running Etoys. > On > first entry to a new EtoysProject, the playground and project

preferences

...

> are initialized to provide an environment similar to that of a > traditional > standalone Etoys image. > > Certain preferences that are required for Etoys are initialized on > project > entry, overriding their global preference values while this

EtoysProject

...

> is active. On leaving the project, these preferences are restored > to > their > previous values. > > "ProjectViewMorph openOn: EtoysProject new" > > Change set attached for a minimal implementation. > > Anyone with Etoys knowledge care to help? I do not know enough > about > Etoys > to fill in the rest of the initialization that will be required, > but > it > should not be hard to do. > > Dave > >

...

Dave

Earlier today login worked. Currently it does not.

--Hannes

On 10/5/17, David T. Lewis lewis@mail.msen.com wrote:

Hannes,

You did not cause the problem. It may have been me, I saved the squeaksource.com image from a VNC session (because I wanted to make an up to date backup of it), and I am now unable to log in to squeaksource. Maybe I triggered a bug :-/

Can you please tell me if you are able to log in to your http://squeaksource.com page? I am getting authorization errors, and I suspect it is a problem that affects everyone.

Thanks, Dave

On Thu, Oct 05, 2017 at 01:52:35AM +0200, H. Hirzel wrote:

...

Dave,

Yes, I encounter problems. They might be related to what I just tried to do:

I wanted to save an updated version of Morphic to the ProjectEtoys repository but by mistake I tried to commit it to the trunk. As I do not have commit rights to trunk this prevented me from changing it inadvertently. Later on I wanted to commit that version to ProjectEtoys. It did not work.

--Hannes

On 10/5/17, David T. Lewis lewis@mail.msen.com wrote:

...

I'm seeing problems with SqueakSource right now, trying to figure out what is wrong. So the project may not be accessible right now :-/

Dave

On Thu, Oct 05, 2017 at 01:17:58AM +0200, H. Hirzel wrote:

...

Karl,

So far entering and existing the Etoys project works smoothly.

Load mcz from into current Squeak 6.0a

MCHttpRepository location: 'http://www.squeaksource.com/EtoysProject' user: '' password: ''

The issue is about providing more settings when entering.

Karl, do you want to be added to the list of developers?

--HH

On 10/5/17, H. Hirzel hannes.hirzel@gmail.com wrote:

...

PasteUpMorph is useful and the functions have to be maintained.

However adding more functions to Morph does not make sense.

Squeak 6.0a Morph selectors size 1345 PasteUpMorph selectors size 530

--Hannes

On 10/4/17, karl ramberg karlramberg@gmail.com wrote:

...

I'm not sure anybody uses Etoys anymore, but PasteUpMorph is very useful in direct manipulation because of it's various layout and event handling options. It also act as a container of other morphs, with automatic layout, enumeration etc. I'm sure most of this could be refactored into Morph class or another class.

Best, Karl

On Tue, Oct 3, 2017 at 3:03 PM, Marcel Taeumel marcel.taeumel@hpi.de wrote:

> +1 :) > > And then later: Rename PasteUpMorph to WorldMorph, and keep an > empty > PasteUpMorph subclass around for compatibility reasons. So many > ideas > have > been ported down to Morph class over the past years. New > applications > have > no reason to ever use other instances of PasteUpMorph. > > Best, > Marcel > > Am 03.10.2017 14:57:55 schrieb H. Hirzel hannes.hirzel@gmail.com: > On 10/3/17, H. Hirzel wrote: > > Dave > > > > your change set contains the class EtoysProject with > > > > EtoysProject selectors > > > > #(#finalEnterActions: #restoreGlobalPreferences > > #saveGlobalPreferences > > #initializeProjectPreferences #configureOnFirstEntry > > #finalExitActions:) > > > > For complete configuration of a EtoysProject it might be > > necessary > > to > > do > > > > PasteUpMorph subclass: EtoysPasteUpMorph > > > > as well. http://wiki.squeak.org/squeak/6461 > > > > Then Etoys related methods may be pushed down to > > EtoysPasteUpMorph. > > See screen shot attached. > > > And probably an Etoys specific subclass of WorldMenu would be > > fine > > as > well > > http://wiki.squeak.org/squeak/6461 > > > > > > there is a test project [2] and some more information about > > adaptions > > needed because of the UI changes in the thread 'Etoys in 2017?' - > > UI > > preferences [3]. And it would be good to have Etoys methods / > > configuration separate [4]. > > > > I suggest that you start go ahead and start implementing this > > while > > using a test Etoys project dropped onto the desktop. > > > > --Hannes > > > > > > [2] > You simply drop it in. E.g. download this project > >> http://etoys.laptop.org/src/Content/ExampleEtoys/CarAndPen.014.pr > > > > [3] Hannes Hirzel, 'Etoys in 2017?' mail, Wed, Feb 22, 2017 at > > 11:01 > > AM > > > > [4] David T. Lewis, Sep 4, 2016 at 3:34 PM > > "I think it would be great if both Etoys and Scratch were easily > > loadable and unloadable in trunk." > > > > On 10/2/17, David T. Lewis wrote: > >> An EtoysProject is a project that is configured for running > >> Etoys. > >> On > >> first entry to a new EtoysProject, the playground and project > preferences > >> are initialized to provide an environment similar to that of a > >> traditional > >> standalone Etoys image. > >> > >> Certain preferences that are required for Etoys are initialized > >> on > >> project > >> entry, overriding their global preference values while this > EtoysProject > >> is active. On leaving the project, these preferences are > >> restored > >> to > >> their > >> previous values. > >> > >> "ProjectViewMorph openOn: EtoysProject new" > >> > >> Change set attached for a minimal implementation. > >> > >> Anyone with Etoys knowledge care to help? I do not know enough > >> about > >> Etoys > >> to fill in the rest of the initialization that will be required, > >> but > >> it > >> should not be hard to do. > >> > >> Dave > >> > >> > > > > > > >

...

We did have a problem on squeaksource.com, but I think it is mostly resolved now.

Hannes,

The password reset for your HJH account was lost, so I set it back to the new password that I sent to you earlier in private email. Hopefully your access is working again now.

Marcel,

Your new account disappeared when squeaksource recovered from some internal problem. Sorry, I do not know the cause. But could I ask you to please register again on squeaksource.com, and I will then add you back to EtoysProject?

Sorry for the disruption, Dave

On Thu, Oct 05, 2017 at 02:03:47AM +0200, H. Hirzel wrote:

Dave

Earlier today login worked. Currently it does not.

--Hannes

On 10/5/17, David T. Lewis lewis@mail.msen.com wrote:

...

Hannes,

You did not cause the problem. It may have been me, I saved the squeaksource.com image from a VNC session (because I wanted to make an up to date backup of it), and I am now unable to log in to squeaksource. Maybe I triggered a bug :-/

Can you please tell me if you are able to log in to your http://squeaksource.com page? I am getting authorization errors, and I suspect it is a problem that affects everyone.

Thanks, Dave

On Thu, Oct 05, 2017 at 01:52:35AM +0200, H. Hirzel wrote:

...

Dave,

Yes, I encounter problems. They might be related to what I just tried to do:

I wanted to save an updated version of Morphic to the ProjectEtoys repository but by mistake I tried to commit it to the trunk. As I do not have commit rights to trunk this prevented me from changing it inadvertently. Later on I wanted to commit that version to ProjectEtoys. It did not work.

--Hannes

On 10/5/17, David T. Lewis lewis@mail.msen.com wrote:

...

I'm seeing problems with SqueakSource right now, trying to figure out what is wrong. So the project may not be accessible right now :-/

Dave

On Thu, Oct 05, 2017 at 01:17:58AM +0200, H. Hirzel wrote:

...

Karl,

So far entering and existing the Etoys project works smoothly.

Load mcz from into current Squeak 6.0a

MCHttpRepository location: 'http://www.squeaksource.com/EtoysProject' user: '' password: ''

The issue is about providing more settings when entering.

Karl, do you want to be added to the list of developers?

--HH

On 10/5/17, H. Hirzel hannes.hirzel@gmail.com wrote:

...

PasteUpMorph is useful and the functions have to be maintained.

However adding more functions to Morph does not make sense.

Squeak 6.0a Morph selectors size 1345 PasteUpMorph selectors size 530

--Hannes

On 10/4/17, karl ramberg karlramberg@gmail.com wrote: > I'm not sure anybody uses Etoys anymore, but PasteUpMorph is very > useful > in > direct manipulation because of it's various layout and event > handling > options. It also act as a container of other morphs, with automatic > layout, enumeration etc. > I'm sure most of this could be refactored into Morph class or > another > class. > > Best, > Karl > > On Tue, Oct 3, 2017 at 3:03 PM, Marcel Taeumel > marcel.taeumel@hpi.de > wrote: > >> +1 :) >> >> And then later: Rename PasteUpMorph to WorldMorph, and keep an >> empty >> PasteUpMorph subclass around for compatibility reasons. So many >> ideas >> have >> been ported down to Morph class over the past years. New >> applications >> have >> no reason to ever use other instances of PasteUpMorph. >> >> Best, >> Marcel >> >> Am 03.10.2017 14:57:55 schrieb H. Hirzel hannes.hirzel@gmail.com: >> On 10/3/17, H. Hirzel wrote: >> > Dave >> > >> > your change set contains the class EtoysProject with >> > >> > EtoysProject selectors >> > >> > #(#finalEnterActions: #restoreGlobalPreferences >> > #saveGlobalPreferences >> > #initializeProjectPreferences #configureOnFirstEntry >> > #finalExitActions:) >> > >> > For complete configuration of a EtoysProject it might be >> > necessary >> > to >> > do >> > >> > PasteUpMorph subclass: EtoysPasteUpMorph >> > >> > as well. http://wiki.squeak.org/squeak/6461 >> > >> > Then Etoys related methods may be pushed down to >> > EtoysPasteUpMorph. >> >> See screen shot attached. >> >> > And probably an Etoys specific subclass of WorldMenu would be >> > fine >> > as >> well >> > http://wiki.squeak.org/squeak/6461 >> > >> > >> > there is a test project [2] and some more information about >> > adaptions >> > needed because of the UI changes in the thread 'Etoys in 2017?' - >> > UI >> > preferences [3]. And it would be good to have Etoys methods / >> > configuration separate [4]. >> > >> > I suggest that you start go ahead and start implementing this >> > while >> > using a test Etoys project dropped onto the desktop. >> > >> > --Hannes >> > >> > >> > [2] > You simply drop it in. E.g. download this project >> >> http://etoys.laptop.org/src/Content/ExampleEtoys/CarAndPen.014.pr >> > >> > [3] Hannes Hirzel, 'Etoys in 2017?' mail, Wed, Feb 22, 2017 at >> > 11:01 >> > AM >> > >> > [4] David T. Lewis, Sep 4, 2016 at 3:34 PM >> > "I think it would be great if both Etoys and Scratch were easily >> > loadable and unloadable in trunk." >> > >> > On 10/2/17, David T. Lewis wrote: >> >> An EtoysProject is a project that is configured for running >> >> Etoys. >> >> On >> >> first entry to a new EtoysProject, the playground and project >> preferences >> >> are initialized to provide an environment similar to that of a >> >> traditional >> >> standalone Etoys image. >> >> >> >> Certain preferences that are required for Etoys are initialized >> >> on >> >> project >> >> entry, overriding their global preference values while this >> EtoysProject >> >> is active. On leaving the project, these preferences are >> >> restored >> >> to >> >> their >> >> previous values. >> >> >> >> "ProjectViewMorph openOn: EtoysProject new" >> >> >> >> Change set attached for a minimal implementation. >> >> >> >> Anyone with Etoys knowledge care to help? I do not know enough >> >> about >> >> Etoys >> >> to fill in the rest of the initialization that will be required, >> >> but >> >> it >> >> should not be hard to do. >> >> >> >> Dave >> >> >> >> >> > >> >> >> >> >> >

...

I added a demo file Morphic-hjh.1354 [11] to the repository

MCHttpRepository location: 'http://www.squeaksource.com/EtoysProject' user: '' password: ''

This file should be loaded into a fully updated trunk test image.

I agree with what Tobias noted earlier in this thread that it is probably better to avoid renaming PasteUpMorph. I see as a solution to easier deal with PasteUpMorph functions the insertion of superclasses of PasteUpMorph (and thus subclasses of BorderedMorph) [12]

The next thing I will come up with is a class MorphWithDnD

a morph class which supports drag and drop. As a superclass of MorphWithGrid

A third class would be PlayField which contains all the Etoys selectors. In an image without Etoys that class would then be just empty.

--Hannes

--------------------

[11] Name: Morphic-hjh.1354 Author: hjh Time: 5 October 2017, 11:51:21.903338 am UUID: e96d5a46-453f-418c-b95f-26f1674ca329 Ancestors: Morphic-hjh.1353

Demo which shows how to remove selectors from PasteUpMorph and insert them into a newy created superclass

Inserted MorphWithGrid as a subclass of BorderedMorph and superclass of PasteUpMorph

gridding protocol was moved from PasteUpMorph to MorphWithGrid

Morphic-hjh.1353: Ancestors: Morphic-hjh.1352

Note: I tried to save this update several times. That accounts for the empty updates in between.

--------- [12] After filing in Morphic-hjh.1354 PasteUpMorph printHierarchy ' ProtoObject #() Object #() Morph #() BorderedMorph #() MorphWithGrid #(''griddingOn'') PasteUpMorph #(...) ComponentLayout #(...) EventTimeline #(...) GeeBookPageMorph #(...) IndexTabs #(...) MouseEventEditor #(...) PartsBin #(...) QuickGuideHolderMorph #(...) SyntaxTestMethods #(...) TetrisBoard #(...) TextPlusPasteUpMorph #(...) WiWPasteUpMorph #(...) MVCWiWPasteUpMorph #(...) Worldlet #(...) ZASMScriptMorph #(...) ZoomAndScrollMorph #(...)'

On 10/5/17, Marcel Taeumel marcel.taeumel@hpi.de wrote:

Done. :)

Best, Marcel Am 05.10.2017 06:21:44 schrieb David T. Lewis lewis@mail.msen.com: We did have a problem on squeaksource.com, but I think it is mostly resolved now.

Hannes,

The password reset for your HJH account was lost, so I set it back to the new password that I sent to you earlier in private email. Hopefully your access is working again now.

Marcel,

Your new account disappeared when squeaksource recovered from some internal problem. Sorry, I do not know the cause. But could I ask you to please register again on squeaksource.com, and I will then add you back to EtoysProject?

Sorry for the disruption, Dave

On Thu, Oct 05, 2017 at 02:03:47AM +0200, H. Hirzel wrote:

...

Dave

Earlier today login worked. Currently it does not.

--Hannes

On 10/5/17, David T. Lewis wrote:

...

Hannes,

You did not cause the problem. It may have been me, I saved the squeaksource.com image from a VNC session (because I wanted to make an up to date backup of it), and I am now unable to log in to squeaksource. Maybe I triggered a bug :-/

Can you please tell me if you are able to log in to your http://squeaksource.com page? I am getting authorization errors, and I suspect it is a problem that affects everyone.

Thanks, Dave

On Thu, Oct 05, 2017 at 01:52:35AM +0200, H. Hirzel wrote:

...

Dave,

Yes, I encounter problems. They might be related to what I just tried to do:

I wanted to save an updated version of Morphic to the ProjectEtoys repository but by mistake I tried to commit it to the trunk. As I do not have commit rights to trunk this prevented me from changing it inadvertently. Later on I wanted to commit that version to ProjectEtoys. It did not work.

--Hannes

On 10/5/17, David T. Lewis wrote:

...

I'm seeing problems with SqueakSource right now, trying to figure out what is wrong. So the project may not be accessible right now :-/

Dave

On Thu, Oct 05, 2017 at 01:17:58AM +0200, H. Hirzel wrote:

...

Karl,

So far entering and existing the Etoys project works smoothly.

Load mcz from into current Squeak 6.0a

MCHttpRepository location: 'http://www.squeaksource.com/EtoysProject' user: '' password: ''

The issue is about providing more settings when entering.

Karl, do you want to be added to the list of developers?

--HH

On 10/5/17, H. Hirzel wrote: > PasteUpMorph is useful and the functions have to be maintained. > > However adding more functions to Morph does not make sense. > > Squeak 6.0a > Morph selectors size 1345 > PasteUpMorph selectors size 530 > > --Hannes > > On 10/4/17, karl ramberg wrote: >> I'm not sure anybody uses Etoys anymore, but PasteUpMorph is >> very >> useful >> in >> direct manipulation because of it's various layout and event >> handling >> options. It also act as a container of other morphs, with >> automatic >> layout, enumeration etc. >> I'm sure most of this could be refactored into Morph class or >> another >> class. >> >> Best, >> Karl >> >> On Tue, Oct 3, 2017 at 3:03 PM, Marcel Taeumel >> >> wrote: >> >>> +1 :) >>> >>> And then later: Rename PasteUpMorph to WorldMorph, and keep an >>> empty >>> PasteUpMorph subclass around for compatibility reasons. So many >>> ideas >>> have >>> been ported down to Morph class over the past years. New >>> applications >>> have >>> no reason to ever use other instances of PasteUpMorph. >>> >>> Best, >>> Marcel >>> >>> Am 03.10.2017 14:57:55 schrieb H. Hirzel : >>> On 10/3/17, H. Hirzel wrote: >>> > Dave >>> > >>> > your change set contains the class EtoysProject with >>> > >>> > EtoysProject selectors >>> > >>> > #(#finalEnterActions: #restoreGlobalPreferences >>> > #saveGlobalPreferences >>> > #initializeProjectPreferences #configureOnFirstEntry >>> > #finalExitActions:) >>> > >>> > For complete configuration of a EtoysProject it might be >>> > necessary >>> > to >>> > do >>> > >>> > PasteUpMorph subclass: EtoysPasteUpMorph >>> > >>> > as well. http://wiki.squeak.org/squeak/6461 >>> > >>> > Then Etoys related methods may be pushed down to >>> > EtoysPasteUpMorph. >>> >>> See screen shot attached. >>> >>> > And probably an Etoys specific subclass of WorldMenu would be >>> > fine >>> > as >>> well >>> > http://wiki.squeak.org/squeak/6461 >>> > >>> > >>> > there is a test project [2] and some more information about >>> > adaptions >>> > needed because of the UI changes in the thread 'Etoys in >>> > 2017?' - >>> > UI >>> > preferences [3]. And it would be good to have Etoys methods / >>> > configuration separate [4]. >>> > >>> > I suggest that you start go ahead and start implementing this >>> > while >>> > using a test Etoys project dropped onto the desktop. >>> > >>> > --Hannes >>> > >>> > >>> > [2] > You simply drop it in. E.g. download this project >>> >> http://etoys.laptop.org/src/Content/ExampleEtoys/CarAndPen.014.pr >>> > >>> > [3] Hannes Hirzel, 'Etoys in 2017?' mail, Wed, Feb 22, 2017 >>> > at >>> > 11:01 >>> > AM >>> > >>> > [4] David T. Lewis, Sep 4, 2016 at 3:34 PM >>> > "I think it would be great if both Etoys and Scratch were >>> > easily >>> > loadable and unloadable in trunk." >>> > >>> > On 10/2/17, David T. Lewis wrote: >>> >> An EtoysProject is a project that is configured for running >>> >> Etoys. >>> >> On >>> >> first entry to a new EtoysProject, the playground and >>> >> project >>> preferences >>> >> are initialized to provide an environment similar to that of >>> >> a >>> >> traditional >>> >> standalone Etoys image. >>> >> >>> >> Certain preferences that are required for Etoys are >>> >> initialized >>> >> on >>> >> project >>> >> entry, overriding their global preference values while this >>> EtoysProject >>> >> is active. On leaving the project, these preferences are >>> >> restored >>> >> to >>> >> their >>> >> previous values. >>> >> >>> >> "ProjectViewMorph openOn: EtoysProject new" >>> >> >>> >> Change set attached for a minimal implementation. >>> >> >>> >> Anyone with Etoys knowledge care to help? I do not know >>> >> enough >>> >> about >>> >> Etoys >>> >> to fill in the rest of the initialization that will be >>> >> required, >>> >> but >>> >> it >>> >> should not be hard to do. >>> >> >>> >> Dave >>> >> >>> >> >>> > >>> >>> >>> >>> >>> >> >

...

A few steps more: when I drop a project file onto the desktop the following methods are called

PasteUpMorph handleDroppedItem: anItem event: anEvent ExternalDropHandler lookupExternalDropHandler: anItem ExternalDropHandler handle: dropStream in: pasteUp dropEvent: anEvent ExternalDropHandler class defaultProjectHandler

ProjectLoading openOn: aMultiByteFileStream: "'/home/user/Downloads/CarAndPen.014(2).pr'"

So we have to fix ProjectLoading

On 10/5/17, H. Hirzel hannes.hirzel@gmail.com wrote:

Note: MorphWithGrid does not really make sense unless you have a superclass MorphWithDnD (Drag and Drop) which handles the morph droped and makes them 'sticky'.

Though refactoring PastUpMorph by inserting superclasses is an issue I suggest to put this on the backburner at the moment and focus on getting the Etoys setting straight as Dave suggests in the initial mail.

A use case to follow: What happens when you drop the exapme project

http://etoys.laptop.org/src/Content/ExampleEtoys/CarAndPen.014.pr

on to the desktop.

ExternalDropHandler>>handleDroppedItem:event: [21]

is called in this case and then dispatches to do the necessary things to deal with the ExampleEtoys/CarAndPen.014.pr file.

There is a message box which needs attention.

And I assume that in the course of these events some settings are necessary. Most prominently to choose EtoysProject and no longer MorphicProject

--Hannes

[21] http://wiki.squeak.org/squeak/4283

On 10/5/17, H. Hirzel hannes.hirzel@gmail.com wrote:

...

I added a demo file Morphic-hjh.1354 [11] to the repository

MCHttpRepository location: 'http://www.squeaksource.com/EtoysProject' user: '' password: ''

This file should be loaded into a fully updated trunk test image.

I agree with what Tobias noted earlier in this thread that it is probably better to avoid renaming PasteUpMorph. I see as a solution to easier deal with PasteUpMorph functions the insertion of superclasses of PasteUpMorph (and thus subclasses of BorderedMorph) [12]

The next thing I will come up with is a class MorphWithDnD

a morph class which supports drag and drop. As a superclass of MorphWithGrid

A third class would be PlayField which contains all the Etoys selectors. In an image without Etoys that class would then be just empty.

--Hannes

---

[11] Name: Morphic-hjh.1354 Author: hjh Time: 5 October 2017, 11:51:21.903338 am UUID: e96d5a46-453f-418c-b95f-26f1674ca329 Ancestors: Morphic-hjh.1353

Demo which shows how to remove selectors from PasteUpMorph and insert them into a newy created superclass

Inserted MorphWithGrid as a subclass of BorderedMorph and superclass of PasteUpMorph

gridding protocol was moved from PasteUpMorph to MorphWithGrid

Morphic-hjh.1353: Ancestors: Morphic-hjh.1352

Note: I tried to save this update several times. That accounts for the empty updates in between.

---

[12] After filing in Morphic-hjh.1354 PasteUpMorph printHierarchy ' ProtoObject #() Object #() Morph #() BorderedMorph #() MorphWithGrid #(''griddingOn'') PasteUpMorph #(...) ComponentLayout #(...) EventTimeline #(...) GeeBookPageMorph #(...) IndexTabs #(...) MouseEventEditor #(...) PartsBin #(...) QuickGuideHolderMorph #(...) SyntaxTestMethods #(...) TetrisBoard #(...) TextPlusPasteUpMorph #(...) WiWPasteUpMorph #(...) MVCWiWPasteUpMorph #(...) Worldlet #(...) ZASMScriptMorph #(...) ZoomAndScrollMorph #(...)'

On 10/5/17, Marcel Taeumel marcel.taeumel@hpi.de wrote:

...

Done. :)

Best, Marcel Am 05.10.2017 06:21:44 schrieb David T. Lewis lewis@mail.msen.com: We did have a problem on squeaksource.com, but I think it is mostly resolved now.

Hannes,

The password reset for your HJH account was lost, so I set it back to the new password that I sent to you earlier in private email. Hopefully your access is working again now.

Marcel,

Your new account disappeared when squeaksource recovered from some internal problem. Sorry, I do not know the cause. But could I ask you to please register again on squeaksource.com, and I will then add you back to EtoysProject?

Sorry for the disruption, Dave

On Thu, Oct 05, 2017 at 02:03:47AM +0200, H. Hirzel wrote:

...

Dave

Earlier today login worked. Currently it does not.

--Hannes

On 10/5/17, David T. Lewis wrote:

...

Hannes,

You did not cause the problem. It may have been me, I saved the squeaksource.com image from a VNC session (because I wanted to make an up to date backup of it), and I am now unable to log in to squeaksource. Maybe I triggered a bug :-/

Can you please tell me if you are able to log in to your http://squeaksource.com page? I am getting authorization errors, and I suspect it is a problem that affects everyone.

Thanks, Dave

On Thu, Oct 05, 2017 at 01:52:35AM +0200, H. Hirzel wrote:

...

Dave,

Yes, I encounter problems. They might be related to what I just tried to do:

I wanted to save an updated version of Morphic to the ProjectEtoys repository but by mistake I tried to commit it to the trunk. As I do not have commit rights to trunk this prevented me from changing it inadvertently. Later on I wanted to commit that version to ProjectEtoys. It did not work.

--Hannes

On 10/5/17, David T. Lewis wrote: > I'm seeing problems with SqueakSource right now, trying to figure > out > what is wrong. So the project may not be accessible right now :-/ > > Dave > > > On Thu, Oct 05, 2017 at 01:17:58AM +0200, H. Hirzel wrote: >> Karl, >> >> So far entering and existing the Etoys project works smoothly. >> >> Load mcz from into current Squeak 6.0a >> >> MCHttpRepository >> location: 'http://www.squeaksource.com/EtoysProject' >> user: '' >> password: '' >> >> The issue is about providing more settings when entering. >> >> Karl, do you want to be added to the list of developers? >> >> --HH >> >> On 10/5/17, H. Hirzel wrote: >> > PasteUpMorph is useful and the functions have to be maintained. >> > >> > However adding more functions to Morph does not make sense. >> > >> > Squeak 6.0a >> > Morph selectors size 1345 >> > PasteUpMorph selectors size 530 >> > >> > --Hannes >> > >> > On 10/4/17, karl ramberg wrote: >> >> I'm not sure anybody uses Etoys anymore, but PasteUpMorph is >> >> very >> >> useful >> >> in >> >> direct manipulation because of it's various layout and event >> >> handling >> >> options. It also act as a container of other morphs, with >> >> automatic >> >> layout, enumeration etc. >> >> I'm sure most of this could be refactored into Morph class or >> >> another >> >> class. >> >> >> >> Best, >> >> Karl >> >> >> >> On Tue, Oct 3, 2017 at 3:03 PM, Marcel Taeumel >> >> >> >> wrote: >> >> >> >>> +1 :) >> >>> >> >>> And then later: Rename PasteUpMorph to WorldMorph, and keep >> >>> an >> >>> empty >> >>> PasteUpMorph subclass around for compatibility reasons. So >> >>> many >> >>> ideas >> >>> have >> >>> been ported down to Morph class over the past years. New >> >>> applications >> >>> have >> >>> no reason to ever use other instances of PasteUpMorph. >> >>> >> >>> Best, >> >>> Marcel >> >>> >> >>> Am 03.10.2017 14:57:55 schrieb H. Hirzel : >> >>> On 10/3/17, H. Hirzel wrote: >> >>> > Dave >> >>> > >> >>> > your change set contains the class EtoysProject with >> >>> > >> >>> > EtoysProject selectors >> >>> > >> >>> > #(#finalEnterActions: #restoreGlobalPreferences >> >>> > #saveGlobalPreferences >> >>> > #initializeProjectPreferences #configureOnFirstEntry >> >>> > #finalExitActions:) >> >>> > >> >>> > For complete configuration of a EtoysProject it might be >> >>> > necessary >> >>> > to >> >>> > do >> >>> > >> >>> > PasteUpMorph subclass: EtoysPasteUpMorph >> >>> > >> >>> > as well. http://wiki.squeak.org/squeak/6461 >> >>> > >> >>> > Then Etoys related methods may be pushed down to >> >>> > EtoysPasteUpMorph. >> >>> >> >>> See screen shot attached. >> >>> >> >>> > And probably an Etoys specific subclass of WorldMenu would >> >>> > be >> >>> > fine >> >>> > as >> >>> well >> >>> > http://wiki.squeak.org/squeak/6461 >> >>> > >> >>> > >> >>> > there is a test project [2] and some more information about >> >>> > adaptions >> >>> > needed because of the UI changes in the thread 'Etoys in >> >>> > 2017?' - >> >>> > UI >> >>> > preferences [3]. And it would be good to have Etoys methods >> >>> > / >> >>> > configuration separate [4]. >> >>> > >> >>> > I suggest that you start go ahead and start implementing >> >>> > this >> >>> > while >> >>> > using a test Etoys project dropped onto the desktop. >> >>> > >> >>> > --Hannes >> >>> > >> >>> > >> >>> > [2] > You simply drop it in. E.g. download this project >> >>> >> http://etoys.laptop.org/src/Content/ExampleEtoys/CarAndPen.014.pr >> >>> > >> >>> > [3] Hannes Hirzel, 'Etoys in 2017?' mail, Wed, Feb 22, 2017 >> >>> > at >> >>> > 11:01 >> >>> > AM >> >>> > >> >>> > [4] David T. Lewis, Sep 4, 2016 at 3:34 PM >> >>> > "I think it would be great if both Etoys and Scratch were >> >>> > easily >> >>> > loadable and unloadable in trunk." >> >>> > >> >>> > On 10/2/17, David T. Lewis wrote: >> >>> >> An EtoysProject is a project that is configured for >> >>> >> running >> >>> >> Etoys. >> >>> >> On >> >>> >> first entry to a new EtoysProject, the playground and >> >>> >> project >> >>> preferences >> >>> >> are initialized to provide an environment similar to that >> >>> >> of >> >>> >> a >> >>> >> traditional >> >>> >> standalone Etoys image. >> >>> >> >> >>> >> Certain preferences that are required for Etoys are >> >>> >> initialized >> >>> >> on >> >>> >> project >> >>> >> entry, overriding their global preference values while >> >>> >> this >> >>> EtoysProject >> >>> >> is active. On leaving the project, these preferences are >> >>> >> restored >> >>> >> to >> >>> >> their >> >>> >> previous values. >> >>> >> >> >>> >> "ProjectViewMorph openOn: EtoysProject new" >> >>> >> >> >>> >> Change set attached for a minimal implementation. >> >>> >> >> >>> >> Anyone with Etoys knowledge care to help? I do not know >> >>> >> enough >> >>> >> about >> >>> >> Etoys >> >>> >> to fill in the rest of the initialization that will be >> >>> >> required, >> >>> >> but >> >>> >> it >> >>> >> should not be hard to do. >> >>> >> >> >>> >> Dave >> >>> >> >> >>> >> >> >>> > >> >>> >> >>> >> >>> >> >>> >> >>> >> >> >> > > > >> > > >

If you drop

http://etoys.laptop.org/src/Content/ExampleEtoys/CarAndPen.014.pr

on to the desktop Squeak asks you for a replacement for 'MultiNewParagraph' as this class was removed in April (The Trunk: EToys-nice.292.mcz)

Answer 'NewParagraph'. Then the Etoys project loads and gives some error messages. Some are related to preferences. An issue to fix first.

Another issue is that actually a MorphicProject is created instead of the new #EtoysProject type we want.

I do not now yet where to do this. The call chain passes through

MultiByteBinaryOrTextStream>>fileInObjectAndCodeForProject [1]

The stream [2] has code and an object to be read by a SmartRefStream.

More investigation needed.

--Hannes

[1] MultiByteBinaryOrTextStream>>fileInObjectAndCodeForProject

fileInObjectAndCodeForProject "This file may contain: 1) a fileIn of code 2) just an object in SmartReferenceStream format 3) both code and an object. File it in and return the object. Note that self must be a FileStream or RWBinaryOrTextStream. Maybe ReadWriteStream incorporate RWBinaryOrTextStream?" | refStream object | self halt. self text. self peek asciiValue = 4 ifTrue: [ "pure object file" self binary. refStream := SmartRefStream on: self. object := refStream nextAndClose] ifFalse: [ "objects mixed with a fileIn" self fileInProject. "reads code and objects, then closes the file" self binary. object := SmartRefStream scannedObject]. "set by side effect of one of the chunks" SmartRefStream scannedObject: nil. "clear scannedObject" ^ object

[2] Content of the Etoys pr file readstream

'''From etoys4.0 of 9 October 2008 [latest update: #2319] on 18 September 2009 at 3:39:18 pm''! | cont | (Smalltalk includesKey: #MorphExtensionPlus) ifFalse: [self inform: ''This project cannot be loaded into an older system.\Please use an OLPC Etoys compatible image.'' translated withCRs. cont _ thisContext. [cont notNil] whileTrue: [ cont selector == #handleEvent: ifTrue: [cont return: nil]. cont _ cont sender. ]]!

!ObjectScanner new initialize!

!self smartRefStream!

On 10/5/17, H. Hirzel hannes.hirzel@gmail.com wrote:

This later on goes to

ProjectLoading class>>

openName: aFileName stream: preStream fromDirectory: aDirectoryOrNil withProjectView: existingView clearOriginFlag: clearOriginFlag "Reconstitute a Morph from the selected file, presumed to represent a Morph saved via the SmartRefStream mechanism, and open it in an appropriate Morphic world."

| morphOrList archive mgr substituteFont numberOfFontSubstitutes

resultArray anObject project manifests dict | (self checkStream: preStream) ifTrue: [^ self]. ProgressNotification signal: '0.2'. archive := preStream isZipArchive ifTrue:[ZipArchive new readFrom: preStream] ifFalse:[nil]. archive ifNotNil:[ manifests := (archive membersMatching: '*manifest'). (manifests size = 1 and: [((dict := self parseManifest: manifests first contents) at: 'Project-Format' ifAbsent: []) = 'S-Expression']) ifTrue: [ ^ (self respondsTo: #openSexpProjectDict:stream:fromDirectory:withProjectView:) ifTrue: [self openSexpProjectDict: dict stream: preStream fromDirectory: aDirectoryOrNil withProjectView: existingView] ifFalse: [self inform: 'Cannot load S-Expression format projects without Etoys' translated]]].

morphOrList := self morphOrList: aFileName stream: preStream fromDirectory: aDirectoryOrNil archive: archive. morphOrList ifNil: [^ self]. ProgressNotification signal: '0.4'. resultArray := self fileInName: aFileName archive: archive morphOrList: morphOrList. anObject := resultArray first. numberOfFontSubstitutes := resultArray second. substituteFont := resultArray third. mgr := resultArray fourth. preStream close. ProgressNotification signal: '0.7'. "the hard part is over" (anObject isKindOf: ImageSegment) ifTrue: [ project := self loadImageSegment: anObject fromDirectory: aDirectoryOrNil withProjectView: existingView numberOfFontSubstitutes: numberOfFontSubstitutes substituteFont: substituteFont mgr: mgr. project noteManifestDetailsIn: dict. project removeParameter: #sugarProperties. Smalltalk at: #SugarPropertiesNotification ifPresent: [:sp | sp signal ifNotNil: [:props | project keepSugarProperties: props monitor: true]]. clearOriginFlag ifTrue: [project forgetExistingURL]. ProgressNotification signal: '0.8'. ^ project ifNil: [self inform: 'No project found in this file' translated] ifNotNil: [ProjectEntryNotification signal: project]]. Project current openViewAndEnter: anObject

On 10/5/17, H. Hirzel hannes.hirzel@gmail.com wrote:

...

A few steps more: when I drop a project file onto the desktop the following methods are called

PasteUpMorph handleDroppedItem: anItem event: anEvent ExternalDropHandler lookupExternalDropHandler: anItem ExternalDropHandler handle: dropStream in: pasteUp dropEvent: anEvent ExternalDropHandler class defaultProjectHandler

ProjectLoading openOn: aMultiByteFileStream: "'/home/user/Downloads/CarAndPen.014(2).pr'"

So we have to fix ProjectLoading

On 10/5/17, H. Hirzel hannes.hirzel@gmail.com wrote:

...

Note: MorphWithGrid does not really make sense unless you have a superclass MorphWithDnD (Drag and Drop) which handles the morph droped and makes them 'sticky'.

Though refactoring PastUpMorph by inserting superclasses is an issue I suggest to put this on the backburner at the moment and focus on getting the Etoys setting straight as Dave suggests in the initial mail.

A use case to follow: What happens when you drop the exapme project

http://etoys.laptop.org/src/Content/ExampleEtoys/CarAndPen.014.pr

on to the desktop.

ExternalDropHandler>>handleDroppedItem:event: [21]

is called in this case and then dispatches to do the necessary things to deal with the ExampleEtoys/CarAndPen.014.pr file.

There is a message box which needs attention.

And I assume that in the course of these events some settings are necessary. Most prominently to choose EtoysProject and no longer MorphicProject

--Hannes

[21] http://wiki.squeak.org/squeak/4283

On 10/5/17, H. Hirzel hannes.hirzel@gmail.com wrote:

...

I added a demo file Morphic-hjh.1354 [11] to the repository

MCHttpRepository location: 'http://www.squeaksource.com/EtoysProject' user: '' password: ''

This file should be loaded into a fully updated trunk test image.

I agree with what Tobias noted earlier in this thread that it is probably better to avoid renaming PasteUpMorph. I see as a solution to easier deal with PasteUpMorph functions the insertion of superclasses of PasteUpMorph (and thus subclasses of BorderedMorph) [12]

The next thing I will come up with is a class MorphWithDnD

a morph class which supports drag and drop. As a superclass of MorphWithGrid

A third class would be PlayField which contains all the Etoys selectors. In an image without Etoys that class would then be just empty.

--Hannes

---

[11] Name: Morphic-hjh.1354 Author: hjh Time: 5 October 2017, 11:51:21.903338 am UUID: e96d5a46-453f-418c-b95f-26f1674ca329 Ancestors: Morphic-hjh.1353

Demo which shows how to remove selectors from PasteUpMorph and insert them into a newy created superclass

Inserted MorphWithGrid as a subclass of BorderedMorph and superclass of PasteUpMorph

gridding protocol was moved from PasteUpMorph to MorphWithGrid

Morphic-hjh.1353: Ancestors: Morphic-hjh.1352

Note: I tried to save this update several times. That accounts for the empty updates in between.

---

[12] After filing in Morphic-hjh.1354 PasteUpMorph printHierarchy ' ProtoObject #() Object #() Morph #() BorderedMorph #() MorphWithGrid #(''griddingOn'') PasteUpMorph #(...) ComponentLayout #(...) EventTimeline #(...) GeeBookPageMorph #(...) IndexTabs #(...) MouseEventEditor #(...) PartsBin #(...) QuickGuideHolderMorph #(...) SyntaxTestMethods #(...) TetrisBoard #(...) TextPlusPasteUpMorph #(...) WiWPasteUpMorph #(...) MVCWiWPasteUpMorph #(...) Worldlet #(...) ZASMScriptMorph #(...) ZoomAndScrollMorph #(...)'

On 10/5/17, Marcel Taeumel marcel.taeumel@hpi.de wrote:

...

Done. :)

Best, Marcel Am 05.10.2017 06:21:44 schrieb David T. Lewis lewis@mail.msen.com: We did have a problem on squeaksource.com, but I think it is mostly resolved now.

Hannes,

The password reset for your HJH account was lost, so I set it back to the new password that I sent to you earlier in private email. Hopefully your access is working again now.

Marcel,

Your new account disappeared when squeaksource recovered from some internal problem. Sorry, I do not know the cause. But could I ask you to please register again on squeaksource.com, and I will then add you back to EtoysProject?

Sorry for the disruption, Dave

On Thu, Oct 05, 2017 at 02:03:47AM +0200, H. Hirzel wrote:

...

Dave

Earlier today login worked. Currently it does not.

--Hannes

On 10/5/17, David T. Lewis wrote: > Hannes, > > You did not cause the problem. It may have been me, I saved the > squeaksource.com > image from a VNC session (because I wanted to make an up to date > backup > of > it), > and I am now unable to log in to squeaksource. Maybe I triggered a > bug > :-/ > > Can you please tell me if you are able to log in to your > http://squeaksource.com > page? I am getting authorization errors, and I suspect it is a > problem > that > affects > everyone. > > Thanks, > Dave > > On Thu, Oct 05, 2017 at 01:52:35AM +0200, H. Hirzel wrote: >> Dave, >> >> Yes, I encounter problems. They might be related to what I just >> tried >> to >> do: >> >> I wanted to save an updated version of Morphic to the ProjectEtoys >> repository but by mistake I tried to commit it to the trunk. As I >> do >> not have commit rights to trunk this prevented me from changing it >> inadvertently. Later on I wanted to commit that version to >> ProjectEtoys. It did not work. >> >> --Hannes >> >> >> >> On 10/5/17, David T. Lewis wrote: >> > I'm seeing problems with SqueakSource right now, trying to >> > figure >> > out >> > what is wrong. So the project may not be accessible right now >> > :-/ >> > >> > Dave >> > >> > >> > On Thu, Oct 05, 2017 at 01:17:58AM +0200, H. Hirzel wrote: >> >> Karl, >> >> >> >> So far entering and existing the Etoys project works smoothly. >> >> >> >> Load mcz from into current Squeak 6.0a >> >> >> >> MCHttpRepository >> >> location: 'http://www.squeaksource.com/EtoysProject' >> >> user: '' >> >> password: '' >> >> >> >> The issue is about providing more settings when entering. >> >> >> >> Karl, do you want to be added to the list of developers? >> >> >> >> --HH >> >> >> >> On 10/5/17, H. Hirzel wrote: >> >> > PasteUpMorph is useful and the functions have to be >> >> > maintained. >> >> > >> >> > However adding more functions to Morph does not make sense. >> >> > >> >> > Squeak 6.0a >> >> > Morph selectors size 1345 >> >> > PasteUpMorph selectors size 530 >> >> > >> >> > --Hannes >> >> > >> >> > On 10/4/17, karl ramberg wrote: >> >> >> I'm not sure anybody uses Etoys anymore, but PasteUpMorph is >> >> >> very >> >> >> useful >> >> >> in >> >> >> direct manipulation because of it's various layout and event >> >> >> handling >> >> >> options. It also act as a container of other morphs, with >> >> >> automatic >> >> >> layout, enumeration etc. >> >> >> I'm sure most of this could be refactored into Morph class >> >> >> or >> >> >> another >> >> >> class. >> >> >> >> >> >> Best, >> >> >> Karl >> >> >> >> >> >> On Tue, Oct 3, 2017 at 3:03 PM, Marcel Taeumel >> >> >> >> >> >> wrote: >> >> >> >> >> >>> +1 :) >> >> >>> >> >> >>> And then later: Rename PasteUpMorph to WorldMorph, and keep >> >> >>> an >> >> >>> empty >> >> >>> PasteUpMorph subclass around for compatibility reasons. So >> >> >>> many >> >> >>> ideas >> >> >>> have >> >> >>> been ported down to Morph class over the past years. New >> >> >>> applications >> >> >>> have >> >> >>> no reason to ever use other instances of PasteUpMorph. >> >> >>> >> >> >>> Best, >> >> >>> Marcel >> >> >>> >> >> >>> Am 03.10.2017 14:57:55 schrieb H. Hirzel : >> >> >>> On 10/3/17, H. Hirzel wrote: >> >> >>> > Dave >> >> >>> > >> >> >>> > your change set contains the class EtoysProject with >> >> >>> > >> >> >>> > EtoysProject selectors >> >> >>> > >> >> >>> > #(#finalEnterActions: #restoreGlobalPreferences >> >> >>> > #saveGlobalPreferences >> >> >>> > #initializeProjectPreferences #configureOnFirstEntry >> >> >>> > #finalExitActions:) >> >> >>> > >> >> >>> > For complete configuration of a EtoysProject it might be >> >> >>> > necessary >> >> >>> > to >> >> >>> > do >> >> >>> > >> >> >>> > PasteUpMorph subclass: EtoysPasteUpMorph >> >> >>> > >> >> >>> > as well. http://wiki.squeak.org/squeak/6461 >> >> >>> > >> >> >>> > Then Etoys related methods may be pushed down to >> >> >>> > EtoysPasteUpMorph. >> >> >>> >> >> >>> See screen shot attached. >> >> >>> >> >> >>> > And probably an Etoys specific subclass of WorldMenu >> >> >>> > would >> >> >>> > be >> >> >>> > fine >> >> >>> > as >> >> >>> well >> >> >>> > http://wiki.squeak.org/squeak/6461 >> >> >>> > >> >> >>> > >> >> >>> > there is a test project [2] and some more information >> >> >>> > about >> >> >>> > adaptions >> >> >>> > needed because of the UI changes in the thread 'Etoys in >> >> >>> > 2017?' - >> >> >>> > UI >> >> >>> > preferences [3]. And it would be good to have Etoys >> >> >>> > methods >> >> >>> > / >> >> >>> > configuration separate [4]. >> >> >>> > >> >> >>> > I suggest that you start go ahead and start implementing >> >> >>> > this >> >> >>> > while >> >> >>> > using a test Etoys project dropped onto the desktop. >> >> >>> > >> >> >>> > --Hannes >> >> >>> > >> >> >>> > >> >> >>> > [2] > You simply drop it in. E.g. download this project >> >> >>> >> http://etoys.laptop.org/src/Content/ExampleEtoys/CarAndPen.014.pr >> >> >>> > >> >> >>> > [3] Hannes Hirzel, 'Etoys in 2017?' mail, Wed, Feb 22, >> >> >>> > 2017 >> >> >>> > at >> >> >>> > 11:01 >> >> >>> > AM >> >> >>> > >> >> >>> > [4] David T. Lewis, Sep 4, 2016 at 3:34 PM >> >> >>> > "I think it would be great if both Etoys and Scratch were >> >> >>> > easily >> >> >>> > loadable and unloadable in trunk." >> >> >>> > >> >> >>> > On 10/2/17, David T. Lewis wrote: >> >> >>> >> An EtoysProject is a project that is configured for >> >> >>> >> running >> >> >>> >> Etoys. >> >> >>> >> On >> >> >>> >> first entry to a new EtoysProject, the playground and >> >> >>> >> project >> >> >>> preferences >> >> >>> >> are initialized to provide an environment similar to >> >> >>> >> that >> >> >>> >> of >> >> >>> >> a >> >> >>> >> traditional >> >> >>> >> standalone Etoys image. >> >> >>> >> >> >> >>> >> Certain preferences that are required for Etoys are >> >> >>> >> initialized >> >> >>> >> on >> >> >>> >> project >> >> >>> >> entry, overriding their global preference values while >> >> >>> >> this >> >> >>> EtoysProject >> >> >>> >> is active. On leaving the project, these preferences are >> >> >>> >> restored >> >> >>> >> to >> >> >>> >> their >> >> >>> >> previous values. >> >> >>> >> >> >> >>> >> "ProjectViewMorph openOn: EtoysProject new" >> >> >>> >> >> >> >>> >> Change set attached for a minimal implementation. >> >> >>> >> >> >> >>> >> Anyone with Etoys knowledge care to help? I do not know >> >> >>> >> enough >> >> >>> >> about >> >> >>> >> Etoys >> >> >>> >> to fill in the rest of the initialization that will be >> >> >>> >> required, >> >> >>> >> but >> >> >>> >> it >> >> >>> >> should not be hard to do. >> >> >>> >> >> >> >>> >> Dave >> >> >>> >> >> >> >>> >> >> >> >>> > >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> >> >> >> > >> > >> > >> >> >> > >> > >> > >> > >

To adapt

#fixUponLoad:seg:

is the issue here if we want to change MorphicProjects to EtoysProjects when loading old Etoys pr projects.

As MorphicProject subclass: #EtoysProject holds an now new instance variables the changes should be minimal. Have all objects from aMorphicProject added to a new EtoysProject and then a become:

Comments?

On 10/5/17, H. Hirzel hannes.hirzel@gmail.com wrote:

Later on in

ProjectLoading class>>loadImageSegment: morphOrList fromDirectory: aDirectoryOrNil withProjectView: existingView numberOfFontSubstitutes: numberOfFontSubstitutes substituteFont: substituteFont mgr: mgr

| proj projectsToBeDeleted ef f | (f := (Flaps globalFlapTabWithID: 'Navigator' translated)) ifNotNil: [f hideFlap]. proj := morphOrList arrayOfRoots detect: [:mm | mm isKindOf: Project] ifNone: [^ nil].

The project 'proj' is read which is a MorphicProject.

We need to convert this into an EtoysProject if we want to follow the path of upgrading MorphicProjects to EtoysProjects.

Probably a good idea but a matter of discussion.

On 10/5/17, H. Hirzel hannes.hirzel@gmail.com wrote:

...

If you drop

http://etoys.laptop.org/src/Content/ExampleEtoys/CarAndPen.014.pr

on to the desktop Squeak asks you for a replacement for 'MultiNewParagraph' as this class was removed in April (The Trunk: EToys-nice.292.mcz)

Answer 'NewParagraph'. Then the Etoys project loads and gives some error messages. Some are related to preferences. An issue to fix first.

Another issue is that actually a MorphicProject is created instead of the new #EtoysProject type we want.

I do not now yet where to do this. The call chain passes through

MultiByteBinaryOrTextStream>>fileInObjectAndCodeForProject [1]

The stream [2] has code and an object to be read by a SmartRefStream.

More investigation needed.

--Hannes

[1] MultiByteBinaryOrTextStream>>fileInObjectAndCodeForProject

fileInObjectAndCodeForProject "This file may contain:

1. a fileIn of code
2. just an object in SmartReferenceStream format
3. both code and an object. File it in and return the object. Note that self must be a

FileStream or RWBinaryOrTextStream. Maybe ReadWriteStream incorporate RWBinaryOrTextStream?" | refStream object | self halt. self text. self peek asciiValue = 4 ifTrue: [ "pure object file" self binary. refStream := SmartRefStream on: self. object := refStream nextAndClose] ifFalse: [ "objects mixed with a fileIn" self fileInProject. "reads code and objects, then closes the file" self binary. object := SmartRefStream scannedObject]. "set by side effect of one of the chunks" SmartRefStream scannedObject: nil. "clear scannedObject" ^ object

[2] Content of the Etoys pr file readstream

'''From etoys4.0 of 9 October 2008 [latest update: #2319] on 18 September 2009 at 3:39:18 pm''! | cont | (Smalltalk includesKey: #MorphExtensionPlus) ifFalse: [self inform: ''This project cannot be loaded into an older system.\Please use an OLPC Etoys compatible image.'' translated withCRs. cont _ thisContext. [cont notNil] whileTrue: [ cont selector == #handleEvent: ifTrue: [cont return: nil]. cont _ cont sender. ]]!

!ObjectScanner new initialize!

!self smartRefStream!

On 10/5/17, H. Hirzel hannes.hirzel@gmail.com wrote:

...

This later on goes to

ProjectLoading class>>

openName: aFileName stream: preStream fromDirectory: aDirectoryOrNil withProjectView: existingView clearOriginFlag: clearOriginFlag "Reconstitute a Morph from the selected file, presumed to represent a Morph saved via the SmartRefStream mechanism, and open it in an appropriate Morphic world."

| morphOrList archive mgr substituteFont numberOfFontSubstitutes

resultArray anObject project manifests dict | (self checkStream: preStream) ifTrue: [^ self]. ProgressNotification signal: '0.2'. archive := preStream isZipArchive ifTrue:[ZipArchive new readFrom: preStream] ifFalse:[nil]. archive ifNotNil:[ manifests := (archive membersMatching: '*manifest'). (manifests size = 1 and: [((dict := self parseManifest: manifests first contents) at: 'Project-Format' ifAbsent: []) = 'S-Expression']) ifTrue: [ ^ (self respondsTo: #openSexpProjectDict:stream:fromDirectory:withProjectView:) ifTrue: [self openSexpProjectDict: dict stream: preStream fromDirectory: aDirectoryOrNil withProjectView: existingView] ifFalse: [self inform: 'Cannot load S-Expression format projects without Etoys' translated]]].

morphOrList := self morphOrList: aFileName stream: preStream fromDirectory: aDirectoryOrNil archive: archive. morphOrList ifNil: [^ self]. ProgressNotification signal: '0.4'. resultArray := self fileInName: aFileName archive: archive morphOrList: morphOrList. anObject := resultArray first. numberOfFontSubstitutes := resultArray second. substituteFont := resultArray third. mgr := resultArray fourth. preStream close. ProgressNotification signal: '0.7'. "the hard part is over" (anObject isKindOf: ImageSegment) ifTrue: [ project := self loadImageSegment: anObject fromDirectory: aDirectoryOrNil withProjectView: existingView numberOfFontSubstitutes: numberOfFontSubstitutes substituteFont: substituteFont mgr: mgr. project noteManifestDetailsIn: dict. project removeParameter: #sugarProperties. Smalltalk at: #SugarPropertiesNotification ifPresent: [:sp | sp signal ifNotNil: [:props | project keepSugarProperties: props monitor: true]]. clearOriginFlag ifTrue: [project forgetExistingURL]. ProgressNotification signal: '0.8'. ^ project ifNil: [self inform: 'No project found in this file' translated] ifNotNil: [ProjectEntryNotification signal: project]]. Project current openViewAndEnter: anObject

On 10/5/17, H. Hirzel hannes.hirzel@gmail.com wrote:

...

A few steps more: when I drop a project file onto the desktop the following methods are called

PasteUpMorph handleDroppedItem: anItem event: anEvent ExternalDropHandler lookupExternalDropHandler: anItem ExternalDropHandler handle: dropStream in: pasteUp dropEvent: anEvent ExternalDropHandler class defaultProjectHandler

ProjectLoading openOn: aMultiByteFileStream: "'/home/user/Downloads/CarAndPen.014(2).pr'"

So we have to fix ProjectLoading

On 10/5/17, H. Hirzel hannes.hirzel@gmail.com wrote:

...

Note: MorphWithGrid does not really make sense unless you have a superclass MorphWithDnD (Drag and Drop) which handles the morph droped and makes them 'sticky'.

Though refactoring PastUpMorph by inserting superclasses is an issue I suggest to put this on the backburner at the moment and focus on getting the Etoys setting straight as Dave suggests in the initial mail.

A use case to follow: What happens when you drop the exapme project

http://etoys.laptop.org/src/Content/ExampleEtoys/CarAndPen.014.pr

on to the desktop.

ExternalDropHandler>>handleDroppedItem:event: [21]

is called in this case and then dispatches to do the necessary things to deal with the ExampleEtoys/CarAndPen.014.pr file.

There is a message box which needs attention.

And I assume that in the course of these events some settings are necessary. Most prominently to choose EtoysProject and no longer MorphicProject

--Hannes

[21] http://wiki.squeak.org/squeak/4283

On 10/5/17, H. Hirzel hannes.hirzel@gmail.com wrote:

...

I added a demo file Morphic-hjh.1354 [11] to the repository

MCHttpRepository location: 'http://www.squeaksource.com/EtoysProject' user: '' password: ''

This file should be loaded into a fully updated trunk test image.

I agree with what Tobias noted earlier in this thread that it is probably better to avoid renaming PasteUpMorph. I see as a solution to easier deal with PasteUpMorph functions the insertion of superclasses of PasteUpMorph (and thus subclasses of BorderedMorph) [12]

The next thing I will come up with is a class MorphWithDnD

a morph class which supports drag and drop. As a superclass of MorphWithGrid

A third class would be PlayField which contains all the Etoys selectors. In an image without Etoys that class would then be just empty.

--Hannes

---

[11] Name: Morphic-hjh.1354 Author: hjh Time: 5 October 2017, 11:51:21.903338 am UUID: e96d5a46-453f-418c-b95f-26f1674ca329 Ancestors: Morphic-hjh.1353

Demo which shows how to remove selectors from PasteUpMorph and insert them into a newy created superclass

Inserted MorphWithGrid as a subclass of BorderedMorph and superclass of PasteUpMorph

gridding protocol was moved from PasteUpMorph to MorphWithGrid

Morphic-hjh.1353: Ancestors: Morphic-hjh.1352

Note: I tried to save this update several times. That accounts for the empty updates in between.

---

[12] After filing in Morphic-hjh.1354 PasteUpMorph printHierarchy ' ProtoObject #() Object #() Morph #() BorderedMorph #() MorphWithGrid #(''griddingOn'') PasteUpMorph #(...) ComponentLayout #(...) EventTimeline #(...) GeeBookPageMorph #(...) IndexTabs #(...) MouseEventEditor #(...) PartsBin #(...) QuickGuideHolderMorph #(...) SyntaxTestMethods #(...) TetrisBoard #(...) TextPlusPasteUpMorph #(...) WiWPasteUpMorph #(...) MVCWiWPasteUpMorph #(...) Worldlet #(...) ZASMScriptMorph #(...) ZoomAndScrollMorph #(...)'

On 10/5/17, Marcel Taeumel marcel.taeumel@hpi.de wrote: > Done. :) > > Best, > Marcel > Am 05.10.2017 06:21:44 schrieb David T. Lewis lewis@mail.msen.com: > We did have a problem on squeaksource.com, but I think it is mostly > resolved > now. > > Hannes, > > The password reset for your HJH account was lost, so I set it back > to > the > new password that I sent to you earlier in private email. Hopefully > your > access is working again now. > > Marcel, > > Your new account disappeared when squeaksource recovered from some > internal > problem. Sorry, I do not know the cause. But could I ask you to > please > register > again on squeaksource.com, and I will then add you back to > EtoysProject? > > Sorry for the disruption, > Dave > > > On Thu, Oct 05, 2017 at 02:03:47AM +0200, H. Hirzel wrote: >> Dave >> >> Earlier today login worked. Currently it does not. >> >> --Hannes >> >> On 10/5/17, David T. Lewis wrote: >> > Hannes, >> > >> > You did not cause the problem. It may have been me, I saved the >> > squeaksource.com >> > image from a VNC session (because I wanted to make an up to date >> > backup >> > of >> > it), >> > and I am now unable to log in to squeaksource. Maybe I triggered >> > a >> > bug >> > :-/ >> > >> > Can you please tell me if you are able to log in to your >> > http://squeaksource.com >> > page? I am getting authorization errors, and I suspect it is a >> > problem >> > that >> > affects >> > everyone. >> > >> > Thanks, >> > Dave >> > >> > On Thu, Oct 05, 2017 at 01:52:35AM +0200, H. Hirzel wrote: >> >> Dave, >> >> >> >> Yes, I encounter problems. They might be related to what I just >> >> tried >> >> to >> >> do: >> >> >> >> I wanted to save an updated version of Morphic to the >> >> ProjectEtoys >> >> repository but by mistake I tried to commit it to the trunk. As >> >> I >> >> do >> >> not have commit rights to trunk this prevented me from changing >> >> it >> >> inadvertently. Later on I wanted to commit that version to >> >> ProjectEtoys. It did not work. >> >> >> >> --Hannes >> >> >> >> >> >> >> >> On 10/5/17, David T. Lewis wrote: >> >> > I'm seeing problems with SqueakSource right now, trying to >> >> > figure >> >> > out >> >> > what is wrong. So the project may not be accessible right now >> >> > :-/ >> >> > >> >> > Dave >> >> > >> >> > >> >> > On Thu, Oct 05, 2017 at 01:17:58AM +0200, H. Hirzel wrote: >> >> >> Karl, >> >> >> >> >> >> So far entering and existing the Etoys project works >> >> >> smoothly. >> >> >> >> >> >> Load mcz from into current Squeak 6.0a >> >> >> >> >> >> MCHttpRepository >> >> >> location: 'http://www.squeaksource.com/EtoysProject' >> >> >> user: '' >> >> >> password: '' >> >> >> >> >> >> The issue is about providing more settings when entering. >> >> >> >> >> >> Karl, do you want to be added to the list of developers? >> >> >> >> >> >> --HH >> >> >> >> >> >> On 10/5/17, H. Hirzel wrote: >> >> >> > PasteUpMorph is useful and the functions have to be >> >> >> > maintained. >> >> >> > >> >> >> > However adding more functions to Morph does not make sense. >> >> >> > >> >> >> > Squeak 6.0a >> >> >> > Morph selectors size 1345 >> >> >> > PasteUpMorph selectors size 530 >> >> >> > >> >> >> > --Hannes >> >> >> > >> >> >> > On 10/4/17, karl ramberg wrote: >> >> >> >> I'm not sure anybody uses Etoys anymore, but PasteUpMorph >> >> >> >> is >> >> >> >> very >> >> >> >> useful >> >> >> >> in >> >> >> >> direct manipulation because of it's various layout and >> >> >> >> event >> >> >> >> handling >> >> >> >> options. It also act as a container of other morphs, with >> >> >> >> automatic >> >> >> >> layout, enumeration etc. >> >> >> >> I'm sure most of this could be refactored into Morph class >> >> >> >> or >> >> >> >> another >> >> >> >> class. >> >> >> >> >> >> >> >> Best, >> >> >> >> Karl >> >> >> >> >> >> >> >> On Tue, Oct 3, 2017 at 3:03 PM, Marcel Taeumel >> >> >> >> >> >> >> >> wrote: >> >> >> >> >> >> >> >>> +1 :) >> >> >> >>> >> >> >> >>> And then later: Rename PasteUpMorph to WorldMorph, and >> >> >> >>> keep >> >> >> >>> an >> >> >> >>> empty >> >> >> >>> PasteUpMorph subclass around for compatibility reasons. >> >> >> >>> So >> >> >> >>> many >> >> >> >>> ideas >> >> >> >>> have >> >> >> >>> been ported down to Morph class over the past years. New >> >> >> >>> applications >> >> >> >>> have >> >> >> >>> no reason to ever use other instances of PasteUpMorph. >> >> >> >>> >> >> >> >>> Best, >> >> >> >>> Marcel >> >> >> >>> >> >> >> >>> Am 03.10.2017 14:57:55 schrieb H. Hirzel : >> >> >> >>> On 10/3/17, H. Hirzel wrote: >> >> >> >>> > Dave >> >> >> >>> > >> >> >> >>> > your change set contains the class EtoysProject with >> >> >> >>> > >> >> >> >>> > EtoysProject selectors >> >> >> >>> > >> >> >> >>> > #(#finalEnterActions: #restoreGlobalPreferences >> >> >> >>> > #saveGlobalPreferences >> >> >> >>> > #initializeProjectPreferences #configureOnFirstEntry >> >> >> >>> > #finalExitActions:) >> >> >> >>> > >> >> >> >>> > For complete configuration of a EtoysProject it might >> >> >> >>> > be >> >> >> >>> > necessary >> >> >> >>> > to >> >> >> >>> > do >> >> >> >>> > >> >> >> >>> > PasteUpMorph subclass: EtoysPasteUpMorph >> >> >> >>> > >> >> >> >>> > as well. http://wiki.squeak.org/squeak/6461 >> >> >> >>> > >> >> >> >>> > Then Etoys related methods may be pushed down to >> >> >> >>> > EtoysPasteUpMorph. >> >> >> >>> >> >> >> >>> See screen shot attached. >> >> >> >>> >> >> >> >>> > And probably an Etoys specific subclass of WorldMenu >> >> >> >>> > would >> >> >> >>> > be >> >> >> >>> > fine >> >> >> >>> > as >> >> >> >>> well >> >> >> >>> > http://wiki.squeak.org/squeak/6461 >> >> >> >>> > >> >> >> >>> > >> >> >> >>> > there is a test project [2] and some more information >> >> >> >>> > about >> >> >> >>> > adaptions >> >> >> >>> > needed because of the UI changes in the thread 'Etoys >> >> >> >>> > in >> >> >> >>> > 2017?' - >> >> >> >>> > UI >> >> >> >>> > preferences [3]. And it would be good to have Etoys >> >> >> >>> > methods >> >> >> >>> > / >> >> >> >>> > configuration separate [4]. >> >> >> >>> > >> >> >> >>> > I suggest that you start go ahead and start >> >> >> >>> > implementing >> >> >> >>> > this >> >> >> >>> > while >> >> >> >>> > using a test Etoys project dropped onto the desktop. >> >> >> >>> > >> >> >> >>> > --Hannes >> >> >> >>> > >> >> >> >>> > >> >> >> >>> > [2] > You simply drop it in. E.g. download this project >> >> >> >>> >> http://etoys.laptop.org/src/Content/ExampleEtoys/CarAndPen.014.pr >> >> >> >>> > >> >> >> >>> > [3] Hannes Hirzel, 'Etoys in 2017?' mail, Wed, Feb 22, >> >> >> >>> > 2017 >> >> >> >>> > at >> >> >> >>> > 11:01 >> >> >> >>> > AM >> >> >> >>> > >> >> >> >>> > [4] David T. Lewis, Sep 4, 2016 at 3:34 PM >> >> >> >>> > "I think it would be great if both Etoys and Scratch >> >> >> >>> > were >> >> >> >>> > easily >> >> >> >>> > loadable and unloadable in trunk." >> >> >> >>> > >> >> >> >>> > On 10/2/17, David T. Lewis wrote: >> >> >> >>> >> An EtoysProject is a project that is configured for >> >> >> >>> >> running >> >> >> >>> >> Etoys. >> >> >> >>> >> On >> >> >> >>> >> first entry to a new EtoysProject, the playground and >> >> >> >>> >> project >> >> >> >>> preferences >> >> >> >>> >> are initialized to provide an environment similar to >> >> >> >>> >> that >> >> >> >>> >> of >> >> >> >>> >> a >> >> >> >>> >> traditional >> >> >> >>> >> standalone Etoys image. >> >> >> >>> >> >> >> >> >>> >> Certain preferences that are required for Etoys are >> >> >> >>> >> initialized >> >> >> >>> >> on >> >> >> >>> >> project >> >> >> >>> >> entry, overriding their global preference values while >> >> >> >>> >> this >> >> >> >>> EtoysProject >> >> >> >>> >> is active. On leaving the project, these preferences >> >> >> >>> >> are >> >> >> >>> >> restored >> >> >> >>> >> to >> >> >> >>> >> their >> >> >> >>> >> previous values. >> >> >> >>> >> >> >> >> >>> >> "ProjectViewMorph openOn: EtoysProject new" >> >> >> >>> >> >> >> >> >>> >> Change set attached for a minimal implementation. >> >> >> >>> >> >> >> >> >>> >> Anyone with Etoys knowledge care to help? I do not >> >> >> >>> >> know >> >> >> >>> >> enough >> >> >> >>> >> about >> >> >> >>> >> Etoys >> >> >> >>> >> to fill in the rest of the initialization that will be >> >> >> >>> >> required, >> >> >> >>> >> but >> >> >> >>> >> it >> >> >> >>> >> should not be hard to do. >> >> >> >>> >> >> >> >> >>> >> Dave >> >> >> >>> >> >> >> >> >>> >> >> >> >> >>> > >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >> >> >> >> > >> >> > >> >> > >> >> >> >> >> > >> >> > >> >> > >> >> >> > >> > >> > >

On 10/5/17, H. Hirzel hannes.hirzel@gmail.com wrote:

#fixUponLoad:seg:

as called in (see mark *******)

ProjectLoading class

loadImageSegment: morphOrList fromDirectory: aDirectoryOrNil withProjectView: existingView numberOfFontSubstitutes: numberOfFontSubstitutes substituteFont: substituteFont mgr: mgr

| proj projectsToBeDeleted ef f |

(f := (Flaps globalFlapTabWithID: 'Navigator' translated)) ifNotNil: [f hideFlap]. proj := morphOrList arrayOfRoots detect: [:mm | mm isKindOf: Project] ifNone: [^ nil]. numberOfFontSubstitutes > 0 ifTrue: [ proj projectParameterAt: #substitutedFont put: substituteFont]. ef := proj projectParameterAt: #eToysFont. (ef isNil or: [ef ~= substituteFont familySizeFace]) ifTrue: [ proj projectParameterAt: #substitutedFont put: substituteFont. ].

proj projectParameters at: #MultiSymbolInWrongPlace put: false. "Yoshiki did not put MultiSymbols into outPointers in older images!"

morphOrList arrayOfRoots do: [:obj | obj fixUponLoad: proj seg: morphOrList "imageSegment ******* "].

(proj projectParameters at: #MultiSymbolInWrongPlace) ifTrue: [ morphOrList arrayOfRoots do: [:obj | (obj isKindOf: Set) ifTrue: [obj rehash]]].

proj resourceManager: mgr. "proj versionFrom: preStream." proj lastDirectory: aDirectoryOrNil. proj setParent: Project current. projectsToBeDeleted := OrderedCollection new. existingView == #none ifFalse: [ self makeExistingView: existingView project: proj projectsToBeDeleted: projectsToBeDeleted]. ChangeSorter allChangeSets add: proj changeSet. Project current projectParameters at: #deleteWhenEnteringNewProject ifPresent: [ :ignored | projectsToBeDeleted add: Project current. Project current removeParameter: #deleteWhenEnteringNewProject. ]. projectsToBeDeleted isEmpty ifFalse: [ proj projectParameters at: #projectsToBeDeleted put: projectsToBeDeleted. ]. proj removeParameter: #eToysFont. ^ proj

On 10/5/17, H. Hirzel hannes.hirzel@gmail.com wrote:

...

To adapt

#fixUponLoad:seg:

is the issue here if we want to change MorphicProjects to EtoysProjects when loading old Etoys pr projects.

As MorphicProject subclass: #EtoysProject holds an now new instance variables the changes should be minimal. Have all objects from aMorphicProject added to a new EtoysProject and then a become:

Comments?

On 10/5/17, H. Hirzel hannes.hirzel@gmail.com wrote:

...

Later on in

ProjectLoading class>>loadImageSegment: morphOrList fromDirectory: aDirectoryOrNil withProjectView: existingView numberOfFontSubstitutes: numberOfFontSubstitutes substituteFont: substituteFont mgr: mgr

| proj projectsToBeDeleted ef f | (f := (Flaps globalFlapTabWithID: 'Navigator' translated)) ifNotNil: [f hideFlap]. proj := morphOrList arrayOfRoots detect: [:mm | mm isKindOf: Project] ifNone: [^ nil].

The project 'proj' is read which is a MorphicProject.

We need to convert this into an EtoysProject if we want to follow the path of upgrading MorphicProjects to EtoysProjects.

Probably a good idea but a matter of discussion.

On 10/5/17, H. Hirzel hannes.hirzel@gmail.com wrote:

...

If you drop

http://etoys.laptop.org/src/Content/ExampleEtoys/CarAndPen.014.pr

on to the desktop Squeak asks you for a replacement for 'MultiNewParagraph' as this class was removed in April (The Trunk: EToys-nice.292.mcz)

Answer 'NewParagraph'. Then the Etoys project loads and gives some error messages. Some are related to preferences. An issue to fix first.

Another issue is that actually a MorphicProject is created instead of the new #EtoysProject type we want.

I do not now yet where to do this. The call chain passes through

MultiByteBinaryOrTextStream>>fileInObjectAndCodeForProject [1]

The stream [2] has code and an object to be read by a SmartRefStream.

More investigation needed.

--Hannes

[1] MultiByteBinaryOrTextStream>>fileInObjectAndCodeForProject

fileInObjectAndCodeForProject "This file may contain:

1. a fileIn of code
2. just an object in SmartReferenceStream format
3. both code and an object. File it in and return the object. Note that self must be a

FileStream or RWBinaryOrTextStream. Maybe ReadWriteStream incorporate RWBinaryOrTextStream?" | refStream object | self halt. self text. self peek asciiValue = 4 ifTrue: [ "pure object file" self binary. refStream := SmartRefStream on: self. object := refStream nextAndClose] ifFalse: [ "objects mixed with a fileIn" self fileInProject. "reads code and objects, then closes the file" self binary. object := SmartRefStream scannedObject]. "set by side effect of one of the chunks" SmartRefStream scannedObject: nil. "clear scannedObject" ^ object

[2] Content of the Etoys pr file readstream

'''From etoys4.0 of 9 October 2008 [latest update: #2319] on 18 September 2009 at 3:39:18 pm''! | cont | (Smalltalk includesKey: #MorphExtensionPlus) ifFalse: [self inform: ''This project cannot be loaded into an older system.\Please use an OLPC Etoys compatible image.'' translated withCRs. cont _ thisContext. [cont notNil] whileTrue: [ cont selector == #handleEvent: ifTrue: [cont return: nil]. cont _ cont sender. ]]!

!ObjectScanner new initialize!

!self smartRefStream!

On 10/5/17, H. Hirzel hannes.hirzel@gmail.com wrote:

...

This later on goes to

ProjectLoading class>>

openName: aFileName stream: preStream fromDirectory: aDirectoryOrNil withProjectView: existingView clearOriginFlag: clearOriginFlag "Reconstitute a Morph from the selected file, presumed to represent a Morph saved via the SmartRefStream mechanism, and open it in an appropriate Morphic world."

| morphOrList archive mgr substituteFont numberOfFontSubstitutes

resultArray anObject project manifests dict | (self checkStream: preStream) ifTrue: [^ self]. ProgressNotification signal: '0.2'. archive := preStream isZipArchive ifTrue:[ZipArchive new readFrom: preStream] ifFalse:[nil]. archive ifNotNil:[ manifests := (archive membersMatching: '*manifest'). (manifests size = 1 and: [((dict := self parseManifest: manifests first contents) at: 'Project-Format' ifAbsent: []) = 'S-Expression']) ifTrue: [ ^ (self respondsTo: #openSexpProjectDict:stream:fromDirectory:withProjectView:) ifTrue: [self openSexpProjectDict: dict stream: preStream fromDirectory: aDirectoryOrNil withProjectView: existingView] ifFalse: [self inform: 'Cannot load S-Expression format projects without Etoys' translated]]].

morphOrList := self morphOrList: aFileName stream: preStream fromDirectory: aDirectoryOrNil archive: archive. morphOrList ifNil: [^ self]. ProgressNotification signal: '0.4'. resultArray := self fileInName: aFileName archive: archive morphOrList: morphOrList. anObject := resultArray first. numberOfFontSubstitutes := resultArray second. substituteFont := resultArray third. mgr := resultArray fourth. preStream close. ProgressNotification signal: '0.7'. "the hard part is over" (anObject isKindOf: ImageSegment) ifTrue: [ project := self loadImageSegment: anObject fromDirectory: aDirectoryOrNil withProjectView: existingView numberOfFontSubstitutes: numberOfFontSubstitutes substituteFont: substituteFont mgr: mgr. project noteManifestDetailsIn: dict. project removeParameter: #sugarProperties. Smalltalk at: #SugarPropertiesNotification ifPresent: [:sp | sp signal ifNotNil: [:props | project keepSugarProperties: props monitor: true]]. clearOriginFlag ifTrue: [project forgetExistingURL]. ProgressNotification signal: '0.8'. ^ project ifNil: [self inform: 'No project found in this file' translated] ifNotNil: [ProjectEntryNotification signal: project]]. Project current openViewAndEnter: anObject

On 10/5/17, H. Hirzel hannes.hirzel@gmail.com wrote:

...

A few steps more: when I drop a project file onto the desktop the following methods are called

PasteUpMorph handleDroppedItem: anItem event: anEvent ExternalDropHandler lookupExternalDropHandler: anItem ExternalDropHandler handle: dropStream in: pasteUp dropEvent: anEvent ExternalDropHandler class defaultProjectHandler

ProjectLoading openOn: aMultiByteFileStream: "'/home/user/Downloads/CarAndPen.014(2).pr'"

So we have to fix ProjectLoading

On 10/5/17, H. Hirzel hannes.hirzel@gmail.com wrote: > Note: MorphWithGrid does not really make sense unless you have a > superclass MorphWithDnD (Drag and Drop) which handles the morph > droped > and makes them 'sticky'. > > Though refactoring PastUpMorph by inserting superclasses is an issue > I > suggest to put this on the backburner at the moment and focus on > getting the Etoys setting straight as Dave suggests in the initial > mail. > > A use case to follow: What happens when you drop the exapme project > > > http://etoys.laptop.org/src/Content/ExampleEtoys/CarAndPen.014.pr > > on to the desktop. > > ExternalDropHandler>>handleDroppedItem:event: [21] > > is called in this case and then dispatches to do the necessary > things > to deal with the > ExampleEtoys/CarAndPen.014.pr > file. > > There is a message box which needs attention. > > And I assume that in the course of these events some settings are > necessary. Most prominently to choose EtoysProject and no longer > MorphicProject > > --Hannes > > [21] http://wiki.squeak.org/squeak/4283 > > On 10/5/17, H. Hirzel hannes.hirzel@gmail.com wrote: >> I added a demo file Morphic-hjh.1354 [11] to the repository >> >> MCHttpRepository >> location: 'http://www.squeaksource.com/EtoysProject' >> user: '' >> password: '' >> >> This file should be loaded into a fully updated trunk test image. >> >> I agree with what Tobias noted earlier in this thread that it is >> probably better to avoid renaming PasteUpMorph. I see as a solution >> to >> easier deal with PasteUpMorph functions the insertion of >> superclasses >> of PasteUpMorph (and thus subclasses of BorderedMorph) [12] >> >> The next thing I will come up with is a class >> MorphWithDnD >> >> a morph class which supports drag and drop. >> As a superclass of MorphWithGrid >> >> A third class would be PlayField which contains all the Etoys >> selectors. >> In an image without Etoys that class would then be just empty. >> >> --Hannes >> >> >> -------------------- >> >> [11] >> Name: Morphic-hjh.1354 >> Author: hjh >> Time: 5 October 2017, 11:51:21.903338 am >> UUID: e96d5a46-453f-418c-b95f-26f1674ca329 >> Ancestors: Morphic-hjh.1353 >> >> Demo which shows how to remove selectors from PasteUpMorph and >> insert >> them into a newy created superclass >> >> Inserted >> MorphWithGrid >> as a subclass of BorderedMorph and superclass of >> PasteUpMorph >> >> gridding protocol was moved from >> PasteUpMorph >> to >> MorphWithGrid >> >> >> Morphic-hjh.1353: >> Ancestors: Morphic-hjh.1352 >> >> Note: I tried to save this update several times. That accounts for >> the >> empty updates in between. >> >> >> --------- >> [12] >> After filing in Morphic-hjh.1354 >> PasteUpMorph printHierarchy ' >> ProtoObject #() >> Object #() >> Morph #() >> BorderedMorph #() >> MorphWithGrid #(''griddingOn'') >> PasteUpMorph #(...) >> ComponentLayout #(...) >> EventTimeline #(...) >> GeeBookPageMorph #(...) >> IndexTabs #(...) >> MouseEventEditor #(...) >> PartsBin #(...) >> QuickGuideHolderMorph #(...) >> SyntaxTestMethods #(...) >> TetrisBoard #(...) >> TextPlusPasteUpMorph #(...) >> WiWPasteUpMorph #(...) >> MVCWiWPasteUpMorph #(...) >> Worldlet #(...) >> ZASMScriptMorph #(...) >> ZoomAndScrollMorph #(...)' >> >> On 10/5/17, Marcel Taeumel marcel.taeumel@hpi.de wrote: >>> Done. :) >>> >>> Best, >>> Marcel >>> Am 05.10.2017 06:21:44 schrieb David T. Lewis >>> lewis@mail.msen.com: >>> We did have a problem on squeaksource.com, but I think it is >>> mostly >>> resolved >>> now. >>> >>> Hannes, >>> >>> The password reset for your HJH account was lost, so I set it back >>> to >>> the >>> new password that I sent to you earlier in private email. >>> Hopefully >>> your >>> access is working again now. >>> >>> Marcel, >>> >>> Your new account disappeared when squeaksource recovered from some >>> internal >>> problem. Sorry, I do not know the cause. But could I ask you to >>> please >>> register >>> again on squeaksource.com, and I will then add you back to >>> EtoysProject? >>> >>> Sorry for the disruption, >>> Dave >>> >>> >>> On Thu, Oct 05, 2017 at 02:03:47AM +0200, H. Hirzel wrote: >>>> Dave >>>> >>>> Earlier today login worked. Currently it does not. >>>> >>>> --Hannes >>>> >>>> On 10/5/17, David T. Lewis wrote: >>>> > Hannes, >>>> > >>>> > You did not cause the problem. It may have been me, I saved the >>>> > squeaksource.com >>>> > image from a VNC session (because I wanted to make an up to >>>> > date >>>> > backup >>>> > of >>>> > it), >>>> > and I am now unable to log in to squeaksource. Maybe I >>>> > triggered >>>> > a >>>> > bug >>>> > :-/ >>>> > >>>> > Can you please tell me if you are able to log in to your >>>> > http://squeaksource.com >>>> > page? I am getting authorization errors, and I suspect it is a >>>> > problem >>>> > that >>>> > affects >>>> > everyone. >>>> > >>>> > Thanks, >>>> > Dave >>>> > >>>> > On Thu, Oct 05, 2017 at 01:52:35AM +0200, H. Hirzel wrote: >>>> >> Dave, >>>> >> >>>> >> Yes, I encounter problems. They might be related to what I >>>> >> just >>>> >> tried >>>> >> to >>>> >> do: >>>> >> >>>> >> I wanted to save an updated version of Morphic to the >>>> >> ProjectEtoys >>>> >> repository but by mistake I tried to commit it to the trunk. >>>> >> As >>>> >> I >>>> >> do >>>> >> not have commit rights to trunk this prevented me from >>>> >> changing >>>> >> it >>>> >> inadvertently. Later on I wanted to commit that version to >>>> >> ProjectEtoys. It did not work. >>>> >> >>>> >> --Hannes >>>> >> >>>> >> >>>> >> >>>> >> On 10/5/17, David T. Lewis wrote: >>>> >> > I'm seeing problems with SqueakSource right now, trying to >>>> >> > figure >>>> >> > out >>>> >> > what is wrong. So the project may not be accessible right >>>> >> > now >>>> >> > :-/ >>>> >> > >>>> >> > Dave >>>> >> > >>>> >> > >>>> >> > On Thu, Oct 05, 2017 at 01:17:58AM +0200, H. Hirzel wrote: >>>> >> >> Karl, >>>> >> >> >>>> >> >> So far entering and existing the Etoys project works >>>> >> >> smoothly. >>>> >> >> >>>> >> >> Load mcz from into current Squeak 6.0a >>>> >> >> >>>> >> >> MCHttpRepository >>>> >> >> location: 'http://www.squeaksource.com/EtoysProject' >>>> >> >> user: '' >>>> >> >> password: '' >>>> >> >> >>>> >> >> The issue is about providing more settings when entering. >>>> >> >> >>>> >> >> Karl, do you want to be added to the list of developers? >>>> >> >> >>>> >> >> --HH >>>> >> >> >>>> >> >> On 10/5/17, H. Hirzel wrote: >>>> >> >> > PasteUpMorph is useful and the functions have to be >>>> >> >> > maintained. >>>> >> >> > >>>> >> >> > However adding more functions to Morph does not make >>>> >> >> > sense. >>>> >> >> > >>>> >> >> > Squeak 6.0a >>>> >> >> > Morph selectors size 1345 >>>> >> >> > PasteUpMorph selectors size 530 >>>> >> >> > >>>> >> >> > --Hannes >>>> >> >> > >>>> >> >> > On 10/4/17, karl ramberg wrote: >>>> >> >> >> I'm not sure anybody uses Etoys anymore, but >>>> >> >> >> PasteUpMorph >>>> >> >> >> is >>>> >> >> >> very >>>> >> >> >> useful >>>> >> >> >> in >>>> >> >> >> direct manipulation because of it's various layout and >>>> >> >> >> event >>>> >> >> >> handling >>>> >> >> >> options. It also act as a container of other morphs, >>>> >> >> >> with >>>> >> >> >> automatic >>>> >> >> >> layout, enumeration etc. >>>> >> >> >> I'm sure most of this could be refactored into Morph >>>> >> >> >> class >>>> >> >> >> or >>>> >> >> >> another >>>> >> >> >> class. >>>> >> >> >> >>>> >> >> >> Best, >>>> >> >> >> Karl >>>> >> >> >> >>>> >> >> >> On Tue, Oct 3, 2017 at 3:03 PM, Marcel Taeumel >>>> >> >> >> >>>> >> >> >> wrote: >>>> >> >> >> >>>> >> >> >>> +1 :) >>>> >> >> >>> >>>> >> >> >>> And then later: Rename PasteUpMorph to WorldMorph, and >>>> >> >> >>> keep >>>> >> >> >>> an >>>> >> >> >>> empty >>>> >> >> >>> PasteUpMorph subclass around for compatibility reasons. >>>> >> >> >>> So >>>> >> >> >>> many >>>> >> >> >>> ideas >>>> >> >> >>> have >>>> >> >> >>> been ported down to Morph class over the past years. >>>> >> >> >>> New >>>> >> >> >>> applications >>>> >> >> >>> have >>>> >> >> >>> no reason to ever use other instances of PasteUpMorph. >>>> >> >> >>> >>>> >> >> >>> Best, >>>> >> >> >>> Marcel >>>> >> >> >>> >>>> >> >> >>> Am 03.10.2017 14:57:55 schrieb H. Hirzel : >>>> >> >> >>> On 10/3/17, H. Hirzel wrote: >>>> >> >> >>> > Dave >>>> >> >> >>> > >>>> >> >> >>> > your change set contains the class EtoysProject with >>>> >> >> >>> > >>>> >> >> >>> > EtoysProject selectors >>>> >> >> >>> > >>>> >> >> >>> > #(#finalEnterActions: #restoreGlobalPreferences >>>> >> >> >>> > #saveGlobalPreferences >>>> >> >> >>> > #initializeProjectPreferences #configureOnFirstEntry >>>> >> >> >>> > #finalExitActions:) >>>> >> >> >>> > >>>> >> >> >>> > For complete configuration of a EtoysProject it might >>>> >> >> >>> > be >>>> >> >> >>> > necessary >>>> >> >> >>> > to >>>> >> >> >>> > do >>>> >> >> >>> > >>>> >> >> >>> > PasteUpMorph subclass: EtoysPasteUpMorph >>>> >> >> >>> > >>>> >> >> >>> > as well. http://wiki.squeak.org/squeak/6461 >>>> >> >> >>> > >>>> >> >> >>> > Then Etoys related methods may be pushed down to >>>> >> >> >>> > EtoysPasteUpMorph. >>>> >> >> >>> >>>> >> >> >>> See screen shot attached. >>>> >> >> >>> >>>> >> >> >>> > And probably an Etoys specific subclass of WorldMenu >>>> >> >> >>> > would >>>> >> >> >>> > be >>>> >> >> >>> > fine >>>> >> >> >>> > as >>>> >> >> >>> well >>>> >> >> >>> > http://wiki.squeak.org/squeak/6461 >>>> >> >> >>> > >>>> >> >> >>> > >>>> >> >> >>> > there is a test project [2] and some more information >>>> >> >> >>> > about >>>> >> >> >>> > adaptions >>>> >> >> >>> > needed because of the UI changes in the thread 'Etoys >>>> >> >> >>> > in >>>> >> >> >>> > 2017?' - >>>> >> >> >>> > UI >>>> >> >> >>> > preferences [3]. And it would be good to have Etoys >>>> >> >> >>> > methods >>>> >> >> >>> > / >>>> >> >> >>> > configuration separate [4]. >>>> >> >> >>> > >>>> >> >> >>> > I suggest that you start go ahead and start >>>> >> >> >>> > implementing >>>> >> >> >>> > this >>>> >> >> >>> > while >>>> >> >> >>> > using a test Etoys project dropped onto the desktop. >>>> >> >> >>> > >>>> >> >> >>> > --Hannes >>>> >> >> >>> > >>>> >> >> >>> > >>>> >> >> >>> > [2] > You simply drop it in. E.g. download this >>>> >> >> >>> > project >>>> >> >> >>> >> http://etoys.laptop.org/src/Content/ExampleEtoys/CarAndPen.014.pr >>>> >> >> >>> > >>>> >> >> >>> > [3] Hannes Hirzel, 'Etoys in 2017?' mail, Wed, Feb >>>> >> >> >>> > 22, >>>> >> >> >>> > 2017 >>>> >> >> >>> > at >>>> >> >> >>> > 11:01 >>>> >> >> >>> > AM >>>> >> >> >>> > >>>> >> >> >>> > [4] David T. Lewis, Sep 4, 2016 at 3:34 PM >>>> >> >> >>> > "I think it would be great if both Etoys and Scratch >>>> >> >> >>> > were >>>> >> >> >>> > easily >>>> >> >> >>> > loadable and unloadable in trunk." >>>> >> >> >>> > >>>> >> >> >>> > On 10/2/17, David T. Lewis wrote: >>>> >> >> >>> >> An EtoysProject is a project that is configured for >>>> >> >> >>> >> running >>>> >> >> >>> >> Etoys. >>>> >> >> >>> >> On >>>> >> >> >>> >> first entry to a new EtoysProject, the playground >>>> >> >> >>> >> and >>>> >> >> >>> >> project >>>> >> >> >>> preferences >>>> >> >> >>> >> are initialized to provide an environment similar to >>>> >> >> >>> >> that >>>> >> >> >>> >> of >>>> >> >> >>> >> a >>>> >> >> >>> >> traditional >>>> >> >> >>> >> standalone Etoys image. >>>> >> >> >>> >> >>>> >> >> >>> >> Certain preferences that are required for Etoys are >>>> >> >> >>> >> initialized >>>> >> >> >>> >> on >>>> >> >> >>> >> project >>>> >> >> >>> >> entry, overriding their global preference values >>>> >> >> >>> >> while >>>> >> >> >>> >> this >>>> >> >> >>> EtoysProject >>>> >> >> >>> >> is active. On leaving the project, these preferences >>>> >> >> >>> >> are >>>> >> >> >>> >> restored >>>> >> >> >>> >> to >>>> >> >> >>> >> their >>>> >> >> >>> >> previous values. >>>> >> >> >>> >> >>>> >> >> >>> >> "ProjectViewMorph openOn: EtoysProject new" >>>> >> >> >>> >> >>>> >> >> >>> >> Change set attached for a minimal implementation. >>>> >> >> >>> >> >>>> >> >> >>> >> Anyone with Etoys knowledge care to help? I do not >>>> >> >> >>> >> know >>>> >> >> >>> >> enough >>>> >> >> >>> >> about >>>> >> >> >>> >> Etoys >>>> >> >> >>> >> to fill in the rest of the initialization that will >>>> >> >> >>> >> be >>>> >> >> >>> >> required, >>>> >> >> >>> >> but >>>> >> >> >>> >> it >>>> >> >> >>> >> should not be hard to do. >>>> >> >> >>> >> >>>> >> >> >>> >> Dave >>>> >> >> >>> >> >>>> >> >> >>> >> >>>> >> >> >>> > >>>> >> >> >>> >>>> >> >> >>> >>>> >> >> >>> >>>> >> >> >>> >>>> >> >> >>> >>>> >> >> >> >>>> >> >> > >>>> >> > >>>> >> > >>>> >> >> >>>> >> > >>>> >> > >>>> >> > >>>> >> >>>> > >>>> > >>>> >>> >>> >> >

On 10/6/17, Bert Freudenberg bert@freudenbergs.de wrote:

On Thu, Oct 5, 2017 at 9:25 PM, H. Hirzel hannes.hirzel@gmail.com wrote:

...

If you drop

http://etoys.laptop.org/src/Content/ExampleEtoys/CarAndPen.014.pr

on to the desktop Squeak asks you for a replacement for 'MultiNewParagraph' as this class was removed in April (The Trunk: EToys-nice.292.mcz)

Answer 'NewParagraph'. Then the Etoys project loads and gives some error messages. Some are related to preferences. An issue to fix first.

Another issue is that actually a MorphicProject is created instead of the new #EtoysProject type we want.

I do not now yet where to do this.

​I can't tell you from memory where exactly to fix this, but the project loading mechanism was designed to be flexible enough to allow all kinds of class changes.

Good to know.

In particular

- we get a MorphicProject when reading the *.pr project file. - we need to convert it to an EtoysProject

Some more investigation needed.

It's awesome you're looking into this :)

• Bert -​

On Fri, Oct 6, 2017 at 2:44 PM, David T. Lewis lewis@mail.msen.com wrote:

So we might have some kind of rule in project loading that says "if the current project is an EtoysProject, and if I am loading a *.pr for a MorphicProject, then make it an EtoysProject". And perhaps when saving a project, we could reverse the rule and always save a project as MorphicProject, because we know that a loader in EtoysProject will know how to do the right thing with it.

​Actually, projects saved from the Squeakland image store a class named "Project​". Since this has been made abstract now, we instead load it as MorphicProject.

​The logic is mostly in SmartRefStream, in this case, #initKnownRenames.

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.

I can see now that I misunderstood one important thing. I was assuming that

a new EtoysProject would open up with a playfield like the one I see when I first start a normal Etoys image. But I see now this is wrong, an Etoys project should initially have an empty playfield, but perhaps there is a one-time setup that happens the very first time that I enter a new EtoysProject from the world of "normal Squeak". So maybe if I enter a new EtoysProject from a MorphicProject or MVCProject, it will automatically load some initial project that sets up the welcoming playfield with a car driving around, but when I load or create new EtoysProjects from there, the new projects would just start with empty playfields.

Am I guessing right?

The only difference in an Etoys project is the initial screen layout, yes. Basically, the menu bar should be replaced with the navigator bar. In theory this should just flip a couple of preferences. I'm not sure why a special "EtoysProject" class would be useful.

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.

UI-wise I'd think in any kind of project there should just be a plain "new project" menu item that would create the same kind of project (MVC/Morphic/etc) as the current one. And only in addition to that would I add items to create other kinds of projects.

- Bert -​

On 10/7/17, David T. Lewis lewis@mail.msen.com wrote:

On Fri, Oct 06, 2017 at 03:48:56PM +0200, Bert Freudenberg wrote:

...

On Fri, Oct 6, 2017 at 2:44 PM, David T. Lewis lewis@mail.msen.com wrote:

...

So we might have some kind of rule in project loading that says "if the current project is an EtoysProject, and if I am loading a *.pr for a MorphicProject, then make it an EtoysProject". And perhaps when saving a project, we could reverse the rule and always save a project as MorphicProject, because we know that a loader in EtoysProject will know how to do the right thing with it.

???Actually, projects saved from the Squeakland image store a class named "Project???". Since this has been made abstract now, we instead load it as MorphicProject.

???The logic is mostly in SmartRefStream, in this case, #initKnownRenames.

Thanks, this is what I was looking for

SmartRefStream>>initKnownRenames.

OLD initKnownRenames renamed at: #FlasherMorph put: #Flasher; at: #AlansTextPlusMorph put: #TextPlusMorph; at: #Project put: #MorphicProject; at: #Presenter put: #EtoysPresenter; yourself

Should probably be NEW

initKnownRenames renamed at: #FlasherMorph put: #Flasher; at: #AlansTextPlusMorph put: #TextPlusMorph; at: #Project put: #MorphicProject; at: #Presenter put: #EtoysPresenter; at: #MultiNewParagraph put: #NewParagraph; "NEW NEW NEW" yourself

Oh, that's good, I did not know about the renaming mechanism. Completely off topic for Etoys, but a similar issue, in UTCDateAndTime I implemented #storeDataOn: and #readDataFrom:size: in DateAndTime so that the serialized objects are always in the old format, and converted back to the new class structure when read back. I do like the idea of projects saved to an "old" serialized format for compatibility, and making anyone who invents a new format be responsible for implementing the conversion. This should work with Etoys projects too (I hope).

+1

...

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?

...

I can see now that I misunderstood one important thing. I was assuming that

...

a new EtoysProject would open up with a playfield like the one I see when I first start a normal Etoys image.

If I understand correctly a playfield is just a PasteUpMorph. Which happens to be light green.

Is it sufficient to just use the regular world PasteUpMorph as the playfield with a light green background color as a hint?

But I see now this is wrong, an

...

...

Etoys project should initially have an empty playfield, but perhaps there is a one-time setup that happens the very first time that I enter a new EtoysProject from the world of "normal Squeak". So maybe if I enter a new EtoysProject from a MorphicProject or MVCProject, it will automatically load some initial project that sets up the welcoming playfield with a car driving around, but when I load or create new EtoysProjects from there, the new projects would just start with empty playfields.

Am I guessing right?

We have to find out.

...

The only difference in an Etoys project is the initial screen layout, yes. Basically, the menu bar should be replaced with the navigator bar.

That could be done as well in a regular MorphicProject where you choose the checkbox 'show main docking bar', have another menu option 'show etoys docking bar'

...

In theory this should just flip a couple of preferences. I'm not sure why a special "EtoysProject" class would be useful.

As you mentioned earlier it helps set the stage when I want to do an Etoys project. It is a place where the preferences are set. Maybe we see this more clearly later.

It might not turn out to be useful at all, and if so we can throw it away.

Yes.

But it least it seems to be helping us talk about how to make it work.

Yes.

Or maybe it's just helping me, but I think I'm starting to understand how things work :-)

...

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.

For deployment images people probably want

- Squeak 6 with Etoys (the current trunk enhanced - I can do MVC project, MorphicProjects and Etoysproject and more) - Squeak 6 with Etoys unloaded - Squeak 6 with Etoys set as main entry screen (Etoys deployment 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.

My mental image too.

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.

Yes.

Finally,

I would want to be able to escape back to my normal Squeak.

Yes.

The sequence of screen shots show a use case.

In an EtoysProject (but could be a MorphicProject where instead of TheWorldMainDockingBar a SugarNavigatorBar is shown)

- drag out a 'playfield', sticks on the world morph, not moveable - paint a car - you may drag the car around - get the halos of the car - click on the blue viewer halo (a menu color error pops up, screen shot 4b, fix below) - you get a viewer for the sketch (i.e. the car)

Not sure if this is the proper way to start working with Etoys .......

Fix for #menuTitleBorderColor preference --- Instead of getting it from Preferences go for userInterfaceTheme

In CategoryView >>addNamePaneTo: header

REPLACE namePane borderColor: Preferences menuTitleBorderColor. WITH namePane borderColor: (self userInterfaceTheme menuTitleBorderColor ifNil: [(Color r: 0.6 g: 0.7 b: 1)]).

...

UI-wise I'd think in any kind of project there should just be a plain "new project" menu item that would create the same kind of project (MVC/Morphic/etc) as the current one.

Yes, a necessary discussion about how the 'Projects' menu should work in the main docking bar.

If we are in a project which has the SugarNavigatorBar, thus an Etoys project a new project will be just another project which has a SugarNavigatorBar, not MVC, not a MorphicProject with a TheWorldMainDockingBar

...

And only in addition to that would I add items to create other kinds of projects.

Yes

...

• Bert -???

Yes, Bert, is it possible to give some more background information?

--Hannes

Next thing to look into.

If I hit the 'previous project' navigation button I get

PasteUpMorph>>#removeModalWindow has been deprecated. The global becomeModal is no longer supported, use e.g. a dialog window

Select Proceed to continue, or close this window to cancel the operation.

see screen shot.

A "fix" which works is just to ignore the deprecation message by putting comment quotes around it.

Besides the fix not being nice I doubt that that returning from a sub EtoysProject should give this result -- the ProjectViewMorph of the subproject should probably not be shown.

--Hannes

On 10/8/17, H. Hirzel hannes.hirzel@gmail.com wrote:

We have

---

Project class

returnToPreviousProject "Return to the project from which this project was entered. Do nothing if the current project has no link to its previous project."

| prevProj | prevProj := CurrentProject previousProject. prevProj ifNotNil: [prevProj enter: true revert: false saveForRevert: false].

---

MorphicProject(Project)

enter: returningFlag revert: revertFlag saveForRevert: saveForRevert "Install my ChangeSet, Transcript, and scheduled views as current globals. If returningFlag is true, we will return to the project from whence the current project was entered; don't change its previousProject link in this case. If saveForRevert is true, save the ImageSegment of the project being left. If revertFlag is true, make stubs for the world of the project being left. If revertWithoutAsking is true in the project being left, then always revert."

...... CurrentProject world triggerEvent: #aboutToLeaveWorld. .....

---

PasteUpMorph

triggerEvent: anEventSelector "Evaluate all actions registered for <anEventSelector>. Return the value of the last registered action."

^(self actionForEvent: anEventSelector) value

---

PasteUpMorph

removeModalWindow self deprecated: 'The global becomeModal is no longer supported, use e.g. a dialog window'. "self modalWindow: nil"

I do not know what the issue is here about a modalWindow. Which modal window?

--Hannes

On 10/8/17, H. Hirzel hannes.hirzel@gmail.com wrote:

...

Next thing to look into.

If I hit the 'previous project' navigation button I get

PasteUpMorph>>#removeModalWindow has been deprecated. The global becomeModal is no longer supported, use e.g. a dialog window

Select Proceed to continue, or close this window to cancel the operation.

see screen shot.

Once upon a time some file selection thingies (including the notorious FileList2) might open at the time a Project exited. If so, they would be deleted automatically as they would no longer be relevant when the Project was reentered. If you look at Morph>>becomeModel the other end of this is also deprecated.

On 10/8/17 4:34 PM, H. Hirzel wrote:

I do not know what the issue is here about a modalWindow. Which modal window?

On 10/8/17, David T. Lewis lewis@mail.msen.com wrote:

On Sun, Oct 08, 2017 at 09:54:24PM +0200, H. Hirzel wrote:

...

The sequence of screen shots show a use case.

In an EtoysProject (but could be a MorphicProject where instead of TheWorldMainDockingBar a SugarNavigatorBar is shown)

• drag out a 'playfield', sticks on the world morph, not moveable
• paint a car
• you may drag the car around
• get the halos of the car
• click on the blue viewer halo (a menu color error pops up, screen

shot 4b, fix below)

• you get a viewer for the sketch (i.e. the car)

Not sure if this is the proper way to start working with Etoys .......

I think I understand now that when I open a normal Etoys image, the first playfield that I see (with the car driving around) is just a normal project.

You mean the PasteUpMorph instance of a MorphicProject.

Is that initial project available as a *.pr file, or on a web site?

You simply drop it in. E.g. download this project http://etoys.laptop.org/src/Content/ExampleEtoys/CarAndPen.014.pr

Link given by Bert F.

See more http://forum.world.st/Etoys-in-2017-tc4932001.html#a4935405 There is as well a HPI 6.0a Etoys image by Tim Felgentreff for experimenting

see mail there.

I am interested in figuring out how to load it into our trunk Squeak (maybe not from a file though, perhaps it could be an initialization method).

File loading mechanism is already in the trunk file

Class ProjectLoading

some more material about it earlier in this thread. 'MorphicProject subclass: #EtoysProject'

I'm not quite sure how it would work, but I am thinking that when opening a new EtoysProject from a "not-Etoys" environment, we could load the intial welcome project if it had not previously been loaded.

Yes.

--Hannes

On 10/9/17, David T. Lewis lewis@mail.msen.com wrote:

On Mon, Oct 09, 2017 at 12:05:16AM +0200, H. Hirzel wrote:

...

On 10/8/17, David T. Lewis lewis@mail.msen.com wrote:

...

Is that initial project available as a *.pr file, or on a web site?

You simply drop it in. E.g. download this project http://etoys.laptop.org/src/Content/ExampleEtoys/CarAndPen.014.pr

Link given by Bert F.

Well d'oh! I did not realize it was the same project, sorry.

I did warn you I was an Etoys newbie ;-)

Thanks, Dave

There are more example projects here http://squeakland.org/tutorials/demos/

With the changes discussed so far in this thread the following projects loads fine as well (screen shot)

http://squeakland.org/content/articles/attach/FollowRoad.012.pr

However if you start clicking for example on the 'turn by' parameter you get

SmalltalkImage>>#associationAt:ifAbsent: has been deprecated. Use Smalltalk globals

Select Proceed to continue, or close this window to cancel the operation.

But these are easy fixes.....

UPDATE -------------

With the changes discussed so far I can load three Etoys projects so far into a Squeak 6.0a image.

Immediate problems so far (there will be more):

1. All the loaded Etoys projects do not have an Etoys navigation bar

2. The loaded Etoys projects have an entry #aboutToLeaveWorld in the actionMap which triggers a deprectated method #removeModalWindow.

Regular MorphicProjects have an empty actionMap.

We have not decided yet where to put

Project current world actionMap removeKey: #aboutToLeaveWorld

(Discussion in thread 'PasteUpMorph>>#removeModalWindow has been deprecated --- what do we need to do?')

3. Not all projects from http://squeakland.org/tutorials/demos/ load.

4. We have to implement the class change from

MultiNewParagraph to NewParagraph A method #multiNewParagraphttfclpomsswfpp0

should do the job.

See discussion in thread 'EToys-nice.292.mcz'

Hannes Hirzel

On 10/9/17, H. Hirzel hannes.hirzel@gmail.com wrote:

When I choose

After successful loading of I choose

'World menu' -> 'previous project'

I get an error message.

PasteUpMorph>>#removeModalWindow has been deprecated. The global becomeModal is no longer supported, use e.g. a dialog window

Reason for this is that in the Etoys project I have as actionMap

Project current world actionMap printString

'an IdentityDictionary(#aboutToLeaveWorld ->
                                WeakMessageSend(#removeModalWindow ->
                                                              a

PasteUpMorph<world>(2880695) [world] ) )'

See detailed analysis in the thread 'PasteUpMorph>>#removeModalWindow has been deprecated --- what do we need to do?'

So if I do Project current world actionMap removeKey: #aboutToLeaveWorld

in a workspace in the EtoysProject before choosing the menu entry 'previous project', I do not get the error message.

Result see screen shot. The question is now to find the proper place for removing this actionMap entry

--Hannes

On 10/9/17, H. Hirzel hannes.hirzel@gmail.com wrote:

...

On 10/9/17, David T. Lewis lewis@mail.msen.com wrote:

...

On Mon, Oct 09, 2017 at 12:05:16AM +0200, H. Hirzel wrote:

...

On 10/8/17, David T. Lewis lewis@mail.msen.com wrote:

...

Is that initial project available as a *.pr file, or on a web site?

You simply drop it in. E.g. download this project http://etoys.laptop.org/src/Content/ExampleEtoys/CarAndPen.014.pr

Link given by Bert F.

Well d'oh! I did not realize it was the same project, sorry.

I did warn you I was an Etoys newbie ;-)

Thanks, Dave

There are more example projects here http://squeakland.org/tutorials/demos/

With the changes discussed so far in this thread the following projects loads fine as well (screen shot)

http://squeakland.org/content/articles/attach/FollowRoad.012.pr

However if you start clicking for example on the 'turn by' parameter you get

SmalltalkImage>>#associationAt:ifAbsent: has been deprecated. Use Smalltalk globals

Select Proceed to continue, or close this window to cancel the operation.

But these are easy fixes.....

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

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

Update: It is now possible to load a project such as home.pr into the 6.0a trunk image. Drop a pr file (downloaded from https://freudenbergs.de/bert/squeakjs/Etoys/Home.007.pr) onto the desktop and it loads without blocking. This is due to fixes done this month so far.

The following notes are written in a way that you can jump in helping to finalize Etoys project loading and setup without having read the earlier messages in this thread.

Issues:

1. Walkback window left on screen after loading --------------------------------------------------------------------

A walk-back window still comes up after home.pr has been loaded. The reason for this still needs to be found out. But just closing the window does not seem to have a negative effect to the functioning of the etoys project.

2. Etoys tiles (TileMorph) ------------------------------------

Incrementing and decrementing values in tiles has been fixed so that it is possible to use the project. It was a problem related to the Environment code.

More tests using the tiles are needed to see if there are more problems such as this.

3. Loading pr files ---------------------------

Please help testing with loading different pr files. Other loading problems are likely to come up. Focus on projects created with Etoys5. ( http://squeakland.org/download/).

Etoys 5.0 uses the image format 6502 (http://wiki.squeak.org/squeak/6502). Loading of this format is done in Smalltalk code (not VM code) in 6.0a trunk (class LegacyImageSegment / ImageSegmentLoader). [1]

SmartRefStream does the conversion of the loaded objects if necessary.

4. Cleanup of a loaded project -------------------------------------------

A loaded project is not yet properly set up. The button 'previous project' does not work.

To fix this

EtoysProject >> #finalEnterActions:

needs to be set up.

The call

self world actionMap removeKey: #aboutToLeaveWorld

as discussed earlier in this thread is one a cleanup actions to be here.

When loading a pr file an instance of MorphicProject is created as currently

MorphicProject->EtoysProject

has not been mapped yet in SmartRefStream initKnownRenames. This needs to be done.

--Hannes

-------------------------------------------------------------

[1] There are quite a number of etoys pr files around which are not in the 6502 format. http://wiki.squeak.org/squeak/6502

To fix this other versions of LegacyImageSegment / ImageSegmentLoader are probably necessary.

On 10/14/17, Marcel Taeumel marcel.taeumel@hpi.de wrote:

Hi Hannes,

if you have project instances that need clean-up, you can put that code at one of several checkpoints:

• entering a project (EtoysProject >> #finalEnterActions:)
• leaving a project (EtoysProject >> #finalExitActions:)
• loading/merging a Monticello package (see postLoad scripts)
• quitting the Squeak image (EtoysProject class >> #shutDown:)
• resuming the Squeak image (EtoysProject class >> #startUp:)
• loading a ChangeSet (see postLoad scripts)

Or if you plan to persist Etoys project in the file system, clean them up manually (e.g. with a workspace and object inspector) and write the clean version back to disk for everybody to share.

Best, Marcel

Am 14.10.2017 12:21:20 schrieb H. Hirzel hannes.hirzel@gmail.com: 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 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 wrote:

...

On Sat, Oct 7, 2017 at 2:17 AM, David T. Lewis 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 -​

On 10/19/17, Marcel Taeumel marcel.taeumel@hpi.de wrote:

Nice! Seems to work somehow. Graphics are kind of messed up:

Still, it is running. It reacts to user input. :)

Best, Marcel

Thank you for the test, Marcel.

Good confirmation in terms of Etoys. :-)

I do not have the issue with the graphics display, see screen shot of the the test I did in Ubuntu 14.04. Let's move the discussion about the graphics to a separate thread and do more tests.

--Hannes

Am 19.10.2017 08:48:20 schrieb H. Hirzel hannes.hirzel@gmail.com: Update: It is now possible to load a project such as home.pr into the 6.0a trunk image. Drop a pr file (downloaded from https://freudenbergs.de/bert/squeakjs/Etoys/Home.007.pr) onto the desktop and it loads without blocking. This is due to fixes done this month so far.

The following notes are written in a way that you can jump in helping to finalize Etoys project loading and setup without having read the earlier messages in this thread.

Issues:

1. Walkback window left on screen after loading

---

A walk-back window still comes up after home.pr has been loaded. The reason for this still needs to be found out. But just closing the window does not seem to have a negative effect to the functioning of the etoys project.

2. Etoys tiles (TileMorph)

---

Incrementing and decrementing values in tiles has been fixed so that it is possible to use the project. It was a problem related to the Environment code.

More tests using the tiles are needed to see if there are more problems such as this.

3. Loading pr files

---

Please help testing with loading different pr files. Other loading problems are likely to come up. Focus on projects created with Etoys5. ( http://squeakland.org/download/).

Etoys 5.0 uses the image format 6502 (http://wiki.squeak.org/squeak/6502). Loading of this format is done in Smalltalk code (not VM code) in 6.0a trunk (class LegacyImageSegment / ImageSegmentLoader). [1]

SmartRefStream does the conversion of the loaded objects if necessary.

4. Cleanup of a loaded project

---

A loaded project is not yet properly set up. The button 'previous project' does not work.

To fix this

EtoysProject >> #finalEnterActions:

needs to be set up.

The call

self world actionMap removeKey: #aboutToLeaveWorld

as discussed earlier in this thread is one a cleanup actions to be here.

When loading a pr file an instance of MorphicProject is created as currently

MorphicProject->EtoysProject

has not been mapped yet in SmartRefStream initKnownRenames. This needs to be done.

--Hannes

---

[1] There are quite a number of etoys pr files around which are not in the 6502 format. http://wiki.squeak.org/squeak/6502

To fix this other versions of LegacyImageSegment / ImageSegmentLoader are probably necessary.

On 10/14/17, Marcel Taeumel wrote:

...

Hi Hannes,

if you have project instances that need clean-up, you can put that code at one of several checkpoints:

• entering a project (EtoysProject >> #finalEnterActions:)
• leaving a project (EtoysProject >> #finalExitActions:)
• loading/merging a Monticello package (see postLoad scripts)
• quitting the Squeak image (EtoysProject class >> #shutDown:)
• resuming the Squeak image (EtoysProject class >> #startUp:)
• loading a ChangeSet (see postLoad scripts)

Or if you plan to persist Etoys project in the file system, clean them up manually (e.g. with a workspace and object inspector) and write the clean version back to disk for everybody to share.

Best, Marcel

Am 14.10.2017 12:21:20 schrieb H. Hirzel : 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 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 wrote:

...

On Sat, Oct 7, 2017 at 2:17 AM, David T. Lewis 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 -​

On 10/19/17, David T. Lewis lewis@mail.msen.com wrote:

Hannes,

Thank you for this summary, it helps a lot. I can load the project,

Dave, that implies that you do not have the graphics problem Marcel encountered, is this correct?

and I note that my VM crashes fairly often when playing with this, so that that will give me something to look into :-)

I don't have time to look further now, but the (old) VM I am using at the moment is:

/usr/local/lib/squeak/5.0-201608171728-64/squeak Croquet Closure Cog[Spur] VM [CoInterpreterPrimitives VMMaker.oscog-cb.1919] Unix built on Sep 25 2016 15:59:10 Compiler: 4.6.3 platform sources revision VM: 201608171728 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Date: Wed Aug 17 10:28:01 2016 -0700 $ Plugins: 201608171728 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ CoInterpreter VMMaker.oscog-cb.1919 uuid: 00a8dd2a-bc8d-4552-b400-be781c8aabec Sep 25 2016 StackToRegisterMappingCogit VMMaker.oscog-cb.1919 uuid: 00a8dd2a-bc8d-4552-b400-be781c8aabec Sep 25 2016

Dave

On Thu, Oct 19, 2017 at 08:48:08AM +0200, H. Hirzel wrote:

...

Update: It is now possible to load a project such as home.pr into the 6.0a trunk image. Drop a pr file (downloaded from https://freudenbergs.de/bert/squeakjs/Etoys/Home.007.pr) onto the desktop and it loads without blocking. This is due to fixes done this month so far.

The following notes are written in a way that you can jump in helping to finalize Etoys project loading and setup without having read the earlier messages in this thread.

Issues:

1. Walkback window left on screen after loading

---

A walk-back window still comes up after home.pr has been loaded. The reason for this still needs to be found out. But just closing the window does not seem to have a negative effect to the functioning of the etoys project.

2. Etoys tiles (TileMorph)

---

Incrementing and decrementing values in tiles has been fixed so that it is possible to use the project. It was a problem related to the Environment code.

More tests using the tiles are needed to see if there are more problems such as this.

3. Loading pr files

---

Please help testing with loading different pr files. Other loading problems are likely to come up. Focus on projects created with Etoys5. ( http://squeakland.org/download/).

Etoys 5.0 uses the image format 6502 (http://wiki.squeak.org/squeak/6502). Loading of this format is done in Smalltalk code (not VM code) in 6.0a trunk (class LegacyImageSegment / ImageSegmentLoader). [1]

SmartRefStream does the conversion of the loaded objects if necessary.

4. Cleanup of a loaded project

---

A loaded project is not yet properly set up. The button 'previous project' does not work.

To fix this

 EtoysProject >> #finalEnterActions:

needs to be set up.

The call

 self world actionMap removeKey: #aboutToLeaveWorld

as discussed earlier in this thread is one a cleanup actions to be here.

When loading a pr file an instance of MorphicProject is created as currently

      MorphicProject->EtoysProject

has not been mapped yet in SmartRefStream initKnownRenames. This needs to be done.

--Hannes

---

[1] There are quite a number of etoys pr files around which are not in the 6502 format. http://wiki.squeak.org/squeak/6502

To fix this other versions of LegacyImageSegment / ImageSegmentLoader are probably necessary.

On 10/14/17, Marcel Taeumel marcel.taeumel@hpi.de wrote:

...

Hi Hannes,

if you have project instances that need clean-up, you can put that code at one of several checkpoints:

• entering a project (EtoysProject >> #finalEnterActions:)
• leaving a project (EtoysProject >> #finalExitActions:)
• loading/merging a Monticello package (see postLoad scripts)
• quitting the Squeak image (EtoysProject class >> #shutDown:)
• resuming the Squeak image (EtoysProject class >> #startUp:)
• loading a ChangeSet (see postLoad scripts)

Or if you plan to persist Etoys project in the file system, clean them up manually (e.g. with a workspace and object inspector) and write the clean version back to disk for everybody to share.

Best, Marcel

Am 14.10.2017 12:21:20 schrieb H. Hirzel hannes.hirzel@gmail.com: 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 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 wrote:

...

On Sat, Oct 7, 2017 at 2:17 AM, David T. Lewis 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 -???

In the previous mail instead change

"an empty pr file was created with an Etoys docking bar, actually" to an empty project was created with an Etoys docking bar, actually"

In addtion: a pr file dropped into an Etoys project did not trigger the creation of a Sugar Navigation Bar.

On 10/23/17, H. Hirzel hannes.hirzel@gmail.com wrote:

Dave,

I started with an updated trunk image 6.0a-17435.

Then I manually loaded from

MCHttpRepository location: 'http://www.squeaksource.com/EtoysProject' user: '' password: ''

Name: System-dtl.970
Name: Collections-dtl.765
Name: System-dtl.970

I created a new (empty) 'Etoys project' by choosing 'Projects -> New project -> New Etoys project'.

=> an empty pr file was created with an Etoys docking bar, actually called 'Sugar Navigator Flap'.

In a workspace

Project current
    an EtoysProject (Unnamed2) in a PasteUpMorph(3017056) [world]

Then I dropped a pr-file into that project and was expecting that a EtoysProject will result. But I still got

      Project current
          Project current a MorphicProject (JHexagon2) in a

PasteUpMorph<world>(715845) [world]

To load a pr file which contains an Etoys project as an EtoysProject makes sense.

An Etoys project is a MorphicProject (isa-relationship).

     MorphicProject subclass: #EtoysProject

So I wonder why the imported project object was not set to be an EtoysProject instance. I do not have the time to further look into the issue at the moment.

--Hannes

On 10/23/17, H. Hirzel hannes.hirzel@gmail.com wrote:

...

On 10/19/17, David T. Lewis lewis@mail.msen.com wrote:

...

Hannes,

Thank you for this summary, it helps a lot. I can load the project,

Dave, that implies that you do not have the graphics problem Marcel encountered, is this correct?

...

and I note that my VM crashes fairly often when playing with this, so that that will give me something to look into :-)

I don't have time to look further now, but the (old) VM I am using at the moment is:

/usr/local/lib/squeak/5.0-201608171728-64/squeak Croquet Closure Cog[Spur] VM [CoInterpreterPrimitives VMMaker.oscog-cb.1919] Unix built on Sep 25 2016 15:59:10 Compiler: 4.6.3 platform sources revision VM: 201608171728 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Date: Wed Aug 17 10:28:01 2016 -0700 $ Plugins: 201608171728 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ CoInterpreter VMMaker.oscog-cb.1919 uuid: 00a8dd2a-bc8d-4552-b400-be781c8aabec Sep 25 2016 StackToRegisterMappingCogit VMMaker.oscog-cb.1919 uuid: 00a8dd2a-bc8d-4552-b400-be781c8aabec Sep 25 2016

Dave

On Thu, Oct 19, 2017 at 08:48:08AM +0200, H. Hirzel wrote:

...

Update: It is now possible to load a project such as home.pr into the 6.0a trunk image. Drop a pr file (downloaded from https://freudenbergs.de/bert/squeakjs/Etoys/Home.007.pr) onto the desktop and it loads without blocking. This is due to fixes done this month so far.

The following notes are written in a way that you can jump in helping to finalize Etoys project loading and setup without having read the earlier messages in this thread.

Issues:

1. Walkback window left on screen after loading

---

A walk-back window still comes up after home.pr has been loaded. The reason for this still needs to be found out. But just closing the window does not seem to have a negative effect to the functioning of the etoys project.

2. Etoys tiles (TileMorph)

---

Incrementing and decrementing values in tiles has been fixed so that it is possible to use the project. It was a problem related to the Environment code.

More tests using the tiles are needed to see if there are more problems such as this.

3. Loading pr files

---

Please help testing with loading different pr files. Other loading problems are likely to come up. Focus on projects created with Etoys5. ( http://squeakland.org/download/).

Etoys 5.0 uses the image format 6502 (http://wiki.squeak.org/squeak/6502). Loading of this format is done in Smalltalk code (not VM code) in 6.0a trunk (class LegacyImageSegment / ImageSegmentLoader). [1]

SmartRefStream does the conversion of the loaded objects if necessary.

4. Cleanup of a loaded project

---

A loaded project is not yet properly set up. The button 'previous project' does not work.

To fix this

 EtoysProject >> #finalEnterActions:

needs to be set up.

The call

 self world actionMap removeKey: #aboutToLeaveWorld

as discussed earlier in this thread is one a cleanup actions to be here.

When loading a pr file an instance of MorphicProject is created as currently

      MorphicProject->EtoysProject

has not been mapped yet in SmartRefStream initKnownRenames. This needs to be done.

--Hannes

---

[1] There are quite a number of etoys pr files around which are not in the 6502 format. http://wiki.squeak.org/squeak/6502

To fix this other versions of LegacyImageSegment / ImageSegmentLoader are probably necessary.

On 10/14/17, Marcel Taeumel marcel.taeumel@hpi.de wrote:

...

Hi Hannes,

if you have project instances that need clean-up, you can put that code at one of several checkpoints:

• entering a project (EtoysProject >> #finalEnterActions:)
• leaving a project (EtoysProject >> #finalExitActions:)
• loading/merging a Monticello package (see postLoad scripts)
• quitting the Squeak image (EtoysProject class >> #shutDown:)
• resuming the Squeak image (EtoysProject class >> #startUp:)
• loading a ChangeSet (see postLoad scripts)

Or if you plan to persist Etoys project in the file system, clean them up manually (e.g. with a workspace and object inspector) and write the clean version back to disk for everybody to share.

Best, Marcel

Am 14.10.2017 12:21:20 schrieb H. Hirzel hannes.hirzel@gmail.com: 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 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 wrote: > On Sat, Oct 7, 2017 at 2:17 AM, David T. Lewis > 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 -??? >