On 10/3/17, Tobias Pape <Das.Linux at gmx.de> wrote:
>
>> On 03.10.2017, at 15:03, Marcel Taeumel <marcel.taeumel at hpi.de> wrote:
>>
>> +1 :)
>>
>> And then later: Rename PasteUpMorph to WorldMorph, and keep an empty
>> PasteUpMorph subclass around for compatibility reasons. So many ideas have
>> been ported down to Morph class over the past years. New applications have
>> no reason to ever use other instances of PasteUpMorph.
>
> -1
> Except for Background images, gridding, drag-and-drop helpers, etc.
> It should rather be a PlayField (as it comment already states).

PlayField? I do not find a class named 'PlayField' in a current Trunk image.
Which class do you mean?

>
> Also, be wary of the "rename then subclass" deprecation, because if certain
> projects extend the deprecated subclass (And a lot do for PasteUpMorph),
> those extensions will never be used in typical circumstances.
>
> (This also bit me with the ContextPart depercation… Certain tools that hook
> into debugging stuff via ContextPart extensions no longer work as no
> ContextParts will ever be around. Oh well..)
>
> Best regards
> 	-Tobias
>
>>
>> Best,
>> Marcel
>>> Am 03.10.2017 14:57:55 schrieb H. Hirzel <hannes.hirzel at gmail.com>:
>>>
>>> On 10/3/17, H. Hirzel wrote:
>>> > Dave
>>> >
>>> > your change set contains the class EtoysProject with
>>> >
>>> > EtoysProject selectors
>>> >
>>> > #(#finalEnterActions: #restoreGlobalPreferences #saveGlobalPreferences
>>> > #initializeProjectPreferences #configureOnFirstEntry
>>> > #finalExitActions:)
>>> >
>>> > For complete configuration of a EtoysProject it might be necessary to
>>> > do
>>> >
>>> > PasteUpMorph subclass: EtoysPasteUpMorph
>>> >
>>> > as well. http://wiki.squeak.org/squeak/6461
>>> >
>>> > Then Etoys related methods may be pushed down to EtoysPasteUpMorph.
>>>
>>> See screen shot attached.
>>>
>>> > And probably an Etoys specific subclass of WorldMenu would be fine as
>>> > well
>>> > http://wiki.squeak.org/squeak/6461
>>> >
>>> >
>>> > there is a test project [2] and some more information about adaptions
>>> > needed because of the UI changes in the thread 'Etoys in 2017?' - UI
>>> > preferences [3]. And it would be good to have Etoys methods /
>>> > configuration separate [4].
>>> >
>>> > I suggest that you start go ahead and start implementing this while
>>> > using a test Etoys project dropped onto the desktop.
>>> >
>>> > --Hannes
>>> >
>>> >
>>> > [2] > You simply drop it in. E.g. download this project
>>> >> http://etoys.laptop.org/src/Content/ExampleEtoys/CarAndPen.014.pr
>>> >
>>> > [3] Hannes Hirzel, 'Etoys in 2017?' mail, Wed, Feb 22, 2017 at 11:01 AM
>>> >
>>> >
>>> > [4] David T. Lewis, Sep 4, 2016 at 3:34 PM
>>> > "I think it would be great if both Etoys and Scratch were easily
>>> > loadable and unloadable in trunk."
>>> >
>>> > On 10/2/17, David T. Lewis wrote:
>>> >> An EtoysProject is a project that is configured for running Etoys. On
>>> >> first entry to a new EtoysProject, the playground and project
>>> >> preferences
>>> >> are initialized to provide an environment similar to that of a
>>> >> traditional
>>> >> standalone Etoys image.
>>> >>
>>> >> Certain preferences that are required for Etoys are initialized on
>>> >> project
>>> >> entry, overriding their global preference values while this
>>> >> EtoysProject
>>> >> is active. On leaving the project, these preferences are restored to
>>> >> their
>>> >> previous values.
>>> >>
>>> >> "ProjectViewMorph openOn: EtoysProject new"
>>> >>
>>> >> Change set attached for a minimal implementation.
>>> >>
>>> >> Anyone with Etoys knowledge care to help? I do not know enough about
>>> >> Etoys
>>> >> to fill in the rest of the initialization that will be required, but
>>> >> it
>>> >> should not be hard to do.
>>> >>
>>> >> Dave
>>> >>
>>> >>
>>> >
>>>
>>
>
>
>