MorphicProject subclass: #EtoysProject
Locked
1234
1234
Re: MorphicProject subclass: #EtoysProject
 
|
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. 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). >> >> 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. 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? >> >> 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 |
Re: MorphicProject subclass: #EtoysProject
|
|
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 > |
Re: MorphicProject subclass: #EtoysProject
|
|
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. |
Re: MorphicProject subclass: #EtoysProject
|
|
Re: MorphicProject subclass: #EtoysProject
|
|
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. >> > |
Re: MorphicProject subclass: #EtoysProject
|
|
Re: MorphicProject subclass: #EtoysProject
|
|
Re: MorphicProject subclass: #EtoysProject
|
|
Re: MorphicProject subclass: #EtoysProject
|
|
Re: MorphicProject subclass: #EtoysProject
|
|
Re: MorphicProject subclass: #EtoysProject
|
|
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..... |
Re: MorphicProject subclass: #EtoysProject
|
|
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..... > |
Re: MorphicProject subclass: #EtoysProject
|
|
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..... >> > |
Re: MorphicProject subclass: #EtoysProject
|
|
Re: MorphicProject subclass: #EtoysProject
|
|
Re: MorphicProject subclass: #EtoysProject
|
|
Re: MorphicProject subclass: #EtoysProject
|
|
Re: MorphicProject subclass: #EtoysProject
|
Re: MorphicProject subclass: #EtoysProject
|
|
Re: MorphicProject subclass: #EtoysProject
|
|
Nice! Seems to work somehow. Graphics are kind of messed up:  Still, it is running. It reacts to user input. :) Best, Marcel
|
| Free forum by Nabble | Edit this page |