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 at gmail.com> wrote:
> 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
>
>        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
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: EtoysProject_loaded_Screenshot_2017-10-08.png
Type: image/png
Size: 25594 bytes
Desc: not available
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20171008/997baa88/attachment.png>