[squeak-dev] MorphicProject subclass: #EtoysProject
David T. Lewis
lewis at mail.msen.com
Sat Oct 7 00:17:47 UTC 2017
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 at 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
> ???The logic is mostly in SmartRefStream, in this case, #initKnownRenames.
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
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. But I see now this is wrong, an Etoys
> > project should initially have an empty playfield, but perhaps there is a
> > one-time setup that happens the very first time that I enter a new
> > EtoysProject
> > from the world of "normal Squeak". So maybe if I enter a new EtoysProject
> > from a MorphicProject or MVCProject, it will automatically load some
> > initial project that sets up the welcoming playfield with a car driving
> > around, but when I load or create new EtoysProjects from there, the new
> > projects would just start with empty playfields.
> > Am I guessing right?
> The only difference in an Etoys project is the initial screen layout, yes.
> Basically, the menu bar should be replaced with the navigator bar. In
> theory this should just flip a couple of preferences. I'm not sure why a
> special "EtoysProject" class would be useful.
It might not turn out to be useful at all, and if so we can throw it away.
But it least it seems to be helping us talk about how to make it work. 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.
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.
> UI-wise I'd think in any kind of project there should just be a plain "new
> project" menu item that would create the same kind of project
> (MVC/Morphic/etc) as the current one. And only in addition to that would I
> add items to create other kinds of projects.
> - Bert -???
More information about the Squeak-dev