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 hannes.hirzel@gmail.com wrote:
On 10/7/17, David T. Lewis lewis@mail.msen.com wrote:
On Fri, Oct 06, 2017 at 03:48:56PM +0200, Bert Freudenberg wrote:
On Fri, Oct 6, 2017 at 2:44 PM, David T. Lewis lewis@mail.msen.com wrote:
So we might have some kind of rule in project loading that says "if the current project is an EtoysProject, and if I am loading a *.pr for a MorphicProject, then make it an EtoysProject". And perhaps when saving a project, we could reverse the rule and always save a project as MorphicProject, because we know that a loader in EtoysProject will know how to do the right thing with it.
???Actually, projects saved from the Squeakland image store a class named "Project???". Since this has been made abstract now, we instead load it as MorphicProject.
???The logic is mostly in SmartRefStream, in this case, #initKnownRenames.
Thanks, this is what I was looking for
SmartRefStream>>initKnownRenames.
OLD initKnownRenames renamed at: #FlasherMorph put: #Flasher; at: #AlansTextPlusMorph put: #TextPlusMorph; at: #Project put: #MorphicProject; at: #Presenter put: #EtoysPresenter; yourself
Should probably be NEW
initKnownRenames renamed at: #FlasherMorph put: #Flasher; at: #AlansTextPlusMorph put: #TextPlusMorph; at: #Project put: #MorphicProject; at: #Presenter put: #EtoysPresenter; at: #MultiNewParagraph put: #NewParagraph; "NEW NEW NEW" yourself
Oh, that's good, I did not know about the renaming mechanism. Completely off topic for Etoys, but a similar issue, in UTCDateAndTime I implemented #storeDataOn: and #readDataFrom:size: in DateAndTime so that the serialized objects are always in the old format, and converted back to the new class structure when read back. I do like the idea of projects saved to an "old" serialized format for compatibility, and making anyone who invents a new format be responsible for implementing the conversion. This should work with Etoys projects too (I hope).
+1
It's all class-based. E.g. if the shape of a class changed (new / renamed inst vars) that class can provide a "conversion method" that creates an instance with the new layout from the old inst vars (that are loaded as a dictionary). There still is a preference (conversionMethodsAtFileOut) that used to prompt people to provide these conversion methods when they changed a class. But it didn't survive the transition to Monticello, we now have to remember to write conversion methods for instances that may be stored in a project.
To check my understanding, the "conversion method" might be something like #storeDataOn: and #readDataFrom:size: like what I described for DateAndTime, is that right?
I can see now that I misunderstood one important thing. I was assuming that
a new EtoysProject would open up with a playfield like the one I see when I first start a normal Etoys image.
If I understand correctly a playfield is just a PasteUpMorph. Which happens to be light green.
Is it sufficient to just use the regular world PasteUpMorph as the playfield with a light green background color as a hint?
But I see now this is wrong, an
Etoys project should initially have an empty playfield, but perhaps there is a one-time setup that happens the very first time that I enter a new EtoysProject from the world of "normal Squeak". So maybe if I enter a new EtoysProject from a MorphicProject or MVCProject, it will automatically load some initial project that sets up the welcoming playfield with a car driving around, but when I load or create new EtoysProjects from there, the new projects would just start with empty playfields.
Am I guessing right?
We have to find out.
The only difference in an Etoys project is the initial screen layout, yes. Basically, the menu bar should be replaced with the navigator bar.
That could be done as well in a regular MorphicProject where you choose the checkbox 'show main docking bar', have another menu option 'show etoys docking bar'
In theory this should just flip a couple of preferences. I'm not sure why a special "EtoysProject" class would be useful.
As you mentioned earlier it helps set the stage when I want to do an Etoys project. It is a place where the preferences are set. Maybe we see this more clearly later.
It might not turn out to be useful at all, and if so we can throw it away.
Yes.
But it least it seems to be helping us talk about how to make it work.
Yes.
Or maybe it's just helping me, but I think I'm starting to understand how things work :-)
This is different from the Etoys home screen (the clouds and drive-a-car) which is simply a project that would be loaded by the deployment script that creates an Etoys image. It does not have to ship with the general Squeak image.
For deployment images people probably want
- Squeak 6 with Etoys (the current trunk enhanced - I can do MVC
project, MorphicProjects and Etoysproject and more)
- Squeak 6 with Etoys unloaded
- Squeak 6 with Etoys set as main entry screen (Etoys deployment image)
I do not know if it will make sense, but I guess my mental image is an Etoys "deployed image" hosted inside my regular Squeak trunk image.
My mental image too.
So I
guess that I am thinking of the "clouds and drive-a-car" project being loaded the first time that I create a new EtoysProject from normal Squeak, and that somehow the subsequent project navigation within that new "hosted" Etoys would behave is if I were in a stand-alone Etoys image.
Yes.
Finally,
I would want to be able to escape back to my normal Squeak.
Yes.
The sequence of screen shots show a use case.
In an EtoysProject (but could be a MorphicProject where instead of TheWorldMainDockingBar a SugarNavigatorBar is shown)
- drag out a 'playfield', sticks on the world morph, not moveable
- paint a car
- you may drag the car around
- get the halos of the car
- click on the blue viewer halo (a menu color error pops up, screen
shot 4b, fix below)
- you get a viewer for the sketch (i.e. the car)
Not sure if this is the proper way to start working with Etoys .......
Fix for #menuTitleBorderColor preference --- Instead of getting it from Preferences go for userInterfaceTheme
In CategoryView >>addNamePaneTo: header
REPLACE namePane borderColor: Preferences menuTitleBorderColor. WITH namePane borderColor: (self userInterfaceTheme menuTitleBorderColor ifNil: [(Color r: 0.6 g: 0.7 b: 1)]).
UI-wise I'd think in any kind of project there should just be a plain "new project" menu item that would create the same kind of project (MVC/Morphic/etc) as the current one.
Yes, a necessary discussion about how the 'Projects' menu should work in the main docking bar.
If we are in a project which has the SugarNavigatorBar, thus an Etoys project a new project will be just another project which has a SugarNavigatorBar, not MVC, not a MorphicProject with a TheWorldMainDockingBar
And only in addition to that would I add items to create other kinds of projects.
Yes
- Bert -???
Yes, Bert, is it possible to give some more background information?
--Hannes