[squeak-dev] MorphicProject subclass: #EtoysProject

H. Hirzel hannes.hirzel at gmail.com
Sun Oct 8 19:54:24 UTC 2017

On 10/7/17, David T. Lewis <lewis at 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 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
>> MorphicProject.
>> ???The logic is mostly in SmartRefStream, in this case, #initKnownRenames.

Thanks, this is what I was looking for


		at: #FlasherMorph put: #Flasher;
		at: #AlansTextPlusMorph put: #TextPlusMorph;
		at: #Project put: #MorphicProject;
		at: #Presenter put: #EtoysPresenter;

Should probably be NEW

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

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

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.

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

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.


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


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

	namePane borderColor: Preferences menuTitleBorderColor.
	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

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


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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: EtoysProject_1.png
Type: image/png
Size: 62305 bytes
Desc: not available
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20171008/2df30d52/attachment-0006.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: EtoysProject_2.png
Type: image/png
Size: 66367 bytes
Desc: not available
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20171008/2df30d52/attachment-0007.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: EtoysProject_3.png
Type: image/png
Size: 11278 bytes
Desc: not available
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20171008/2df30d52/attachment-0008.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: EtoysProject_4.png
Type: image/png
Size: 15230 bytes
Desc: not available
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20171008/2df30d52/attachment-0009.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: EtoysProject_4b.png
Type: image/png
Size: 30004 bytes
Desc: not available
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20171008/2df30d52/attachment-0010.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: EtoysProject_5.png
Type: image/png
Size: 74647 bytes
Desc: not available
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20171008/2df30d52/attachment-0011.png>

More information about the Squeak-dev mailing list