MorphicProject subclass: #EtoysProject

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
74 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

Re: MorphicProject subclass: #EtoysProject

Hannes Hirzel
On 10/7/17, David T. Lewis <[hidden email]> 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 <[hidden email]>
>> 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



EtoysProject_1.png (83K) Download Attachment
EtoysProject_2.png (88K) Download Attachment
EtoysProject_3.png (15K) Download Attachment
EtoysProject_4.png (20K) Download Attachment
EtoysProject_4b.png (40K) Download Attachment
EtoysProject_5.png (99K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: MorphicProject subclass: #EtoysProject

Hannes Hirzel
Or course for the time being we can use  #initKnownRenames to change from

    #Project

to

    #EtoysProject


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: #EtoysProject;    "NEW NEW NEW"
                at: #Presenter put: #EtoysPresenter;
                at: #MultiNewParagraph put: #NewParagraph;   "NEW NEW NEW"
                yourself


Result
- We maintain a menu entry 'New EtoysProject' which opens an empty Etoys project
- A pr project dropped into another MorphicProject or EtoysProject
opens as an EtoysProject


HJH

On 10/8/17, H. Hirzel <[hidden email]> wrote:

> On 10/7/17, David T. Lewis <[hidden email]> 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 <[hidden email]>
>>> 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
>



EtoysProject_loaded_Screenshot_2017-10-08.png (34K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: MorphicProject subclass: #EtoysProject

Hannes Hirzel
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.



EtoysProject_Previous_project_button_not_working_2017-10-08.png (29K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: MorphicProject subclass: #EtoysProject

Hannes Hirzel
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 <[hidden email]> 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.
>

Reply | Threaded
Open this post in threaded view
|

Re: MorphicProject subclass: #EtoysProject

Hannes Hirzel
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 <[hidden email]> 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 <[hidden email]> 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.
>>
>



EtoysProject_after_return_from_a_sub_EtoysProject.png (72K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: MorphicProject subclass: #EtoysProject

David T. Lewis
When it comes to things like UI themes and many of the global user preferences,
I suspect we need to have a policy of "the usual rules do not apply here" once
we enter into Etoys.

Dave

On Sun, Oct 08, 2017 at 10:46:12PM +0200, H. Hirzel wrote:

> 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 <[hidden email]> 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 <[hidden email]> 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.
> >>
> >


>


Reply | Threaded
Open this post in threaded view
|

Re: MorphicProject subclass: #EtoysProject

Bob Arning-2
In reply to this post by Hannes Hirzel

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?




Reply | Threaded
Open this post in threaded view
|

Re: MorphicProject subclass: #EtoysProject

David T. Lewis
In reply to this post by Hannes Hirzel
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.

Is that initial project available as a *.pr file, or on a web site? 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).

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.

Dave


Reply | Threaded
Open this post in threaded view
|

Re: MorphicProject subclass: #EtoysProject

Hannes Hirzel
On 10/8/17, David T. Lewis <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: MorphicProject subclass: #EtoysProject

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

> On 10/8/17, David T. Lewis <[hidden email]> 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


Reply | Threaded
Open this post in threaded view
|

Re: MorphicProject subclass: #EtoysProject

Hannes Hirzel
On 10/9/17, David T. Lewis <[hidden email]> wrote:

> On Mon, Oct 09, 2017 at 12:05:16AM +0200, H. Hirzel wrote:
>> On 10/8/17, David T. Lewis <[hidden email]> 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.....



FollowTheRoad_Etoys_project_2017-10-09.png (65K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: MorphicProject subclass: #EtoysProject

Hannes Hirzel
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 <[hidden email]> wrote:

> On 10/9/17, David T. Lewis <[hidden email]> wrote:
>> On Mon, Oct 09, 2017 at 12:05:16AM +0200, H. Hirzel wrote:
>>> On 10/8/17, David T. Lewis <[hidden email]> 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.....
>



Result_after_returning_from_a_dropped_EtoysProject_2017-10-09.png (47K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: MorphicProject subclass: #EtoysProject

Hannes Hirzel
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 <[hidden email]> 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 <[hidden email]> wrote:
>> On 10/9/17, David T. Lewis <[hidden email]> wrote:
>>> On Mon, Oct 09, 2017 at 12:05:16AM +0200, H. Hirzel wrote:
>>>> On 10/8/17, David T. Lewis <[hidden email]> 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.....
>>
>



EtoysProjects_dropped_into_Squeak6.0a_2017-10-09.png (144K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: MorphicProject subclass: #EtoysProject

Bert Freudenberg
In reply to this post by David T. Lewis
On Mon, Oct 9, 2017 at 12:28 AM, David T. Lewis <[hidden email]> wrote:
On Mon, Oct 09, 2017 at 12:05:16AM +0200, H. Hirzel wrote:
> On 10/8/17, David T. Lewis <[hidden email]> 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.

​It's not actually that project :)

If you have a version of Etoys, it's the "Home.007.pr" file in the Resources directory.
"ReleaseBuilderSqueakland new buildInitialScreen" loads this and two other projects.

Etoys on SqueakJS uses https://freudenbergs.de/bert/squeakjs/Etoys/sqindex.json and similar index files in the subfolders to fetch its template files on demand. So these are the three pre-loaded projects:

The canonical source for this used to be a subversion repository at http://etoys.squeak.org/svn but we lost that in the rackspace server move. ​Or, at least we lost the web access to it, the files should still be there, I think.

- Bert -


Reply | Threaded
Open this post in threaded view
|

Re: MorphicProject subclass: #EtoysProject

Bert Freudenberg
In reply to this post by David T. Lewis
On Sat, Oct 7, 2017 at 2:17 AM, David T. Lewis <[hidden email]> 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 -​


Reply | Threaded
Open this post in threaded view
|

Re: MorphicProject subclass: #EtoysProject

Hannes Hirzel
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 <[hidden email]> wrote:

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

Reply | Threaded
Open this post in threaded view
|

Re: MorphicProject subclass: #EtoysProject

Hannes 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 <[hidden email]> 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 <[hidden email]> wrote:
>> On Sat, Oct 7, 2017 at 2:17 AM, David T. Lewis <[hidden email]>
>> 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 -​
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: MorphicProject subclass: #EtoysProject

marcel.taeumel
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 <[hidden email]>:

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



Reply | Threaded
Open this post in threaded view
|

Re: MorphicProject subclass: #EtoysProject

Hannes Hirzel
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 <[hidden email]> 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 <[hidden email]>:
> 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 -​
>>>
>>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: MorphicProject subclass: #EtoysProject

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


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

Best,
Marcel

Am 19.10.2017 08:48:20 schrieb H. Hirzel <[hidden email]>:

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



1234