MorphicProject subclass: #EtoysProject

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
63 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

MorphicProject subclass: #EtoysProject

David T. Lewis
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




EtoysProject-dtl.4.cs (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: MorphicProject subclass: #EtoysProject

Hannes Hirzel
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.
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 <[hidden email]> 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
>
>

Reply | Threaded
Open this post in threaded view
|

Re: MorphicProject subclass: #EtoysProject

Hannes Hirzel
On 10/3/17, H. Hirzel <[hidden email]> 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 <[hidden email]> 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
>>
>>
>



Etoys_methods_in_PasteUpMorph_2017-10-03.png (98K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: MorphicProject subclass: #EtoysProject

marcel.taeumel
+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.

Best,
Marcel

Am 03.10.2017 14:57:55 schrieb H. Hirzel <[hidden email]>:

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



Reply | Threaded
Open this post in threaded view
|

Re: MorphicProject subclass: #EtoysProject

Tobias Pape

> On 03.10.2017, at 15:03, Marcel Taeumel <[hidden email]> 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).

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 <[hidden email]>:
>>
>> 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
>> >>
>> >>
>> >
>>
>


Reply | Threaded
Open this post in threaded view
|

Re: MorphicProject subclass: #EtoysProject

Hannes Hirzel
On 10/3/17, Tobias Pape <[hidden email]> wrote:

>
>> On 03.10.2017, at 15:03, Marcel Taeumel <[hidden email]> 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 <[hidden email]>:
>>>
>>> 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
>>> >>
>>> >>
>>> >
>>>
>>
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: MorphicProject subclass: #EtoysProject

Hannes Hirzel
What Marcel refers to

Morph
   BorderedMorph
        PasteUpMorph    "maintains the current tasks of Background
images, gridding,
                                  drag-and-drop helpers"
            EtoysMorph     "keeps Etoys specific messages"


And then

Morph
   BorderedMorph
        WorldMorph   (PasteUpMorph renamed, methods such as gridding maintained)
            PasteUpMorph    "empty PasteUpMorph class for compatibility"
                EtoysPasteUpMorph     "keeps Etoys specific messages"


Another issue not discussed here is that PasteUpMorph includes
WorldMorph functions.

Pharo has separated this. This is an issue which comes up from time to
time. [5] The advantage of keeping them together is that you may have
worlds in worlds. But this discussion is not related to the issue
Etoys refactoring issue.

--Hannes

[5] http://forum.world.st/WorldMorph-subclass-PasteUpMorph-tp4946461p4946465.html

On 10/3/17, H. Hirzel <[hidden email]> wrote:

> On 10/3/17, Tobias Pape <[hidden email]> wrote:
>>
>>> On 03.10.2017, at 15:03, Marcel Taeumel <[hidden email]> 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 <[hidden email]>:
>>>>
>>>> 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
>>>> >>
>>>> >>
>>>> >
>>>>
>>>
>>
>>
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: MorphicProject subclass: #EtoysProject

marcel.taeumel
@Tobias: In the future, we should get the project-specific parts of PasteUpMorph extracted into sth. called WorldMorph to be used only as the global "desktop thingy" for Morphic projects. The currently mixed state is really confusing. If there is other left-over stuff not yet ready for the Morph base class (gridding?), we could add an additional "Playfield", too. Not sure about the name, though. :)

I do not think that it is worth supporting existing code that relies on "PasteUpMorph allInstances" to work in its current form. Same for "ContextPart allInstances".

Best,
Marcel

Am 03.10.2017 15:34:25 schrieb H. Hirzel <[hidden email]>:

What Marcel refers to

Morph
BorderedMorph
PasteUpMorph "maintains the current tasks of Background
images, gridding,
drag-and-drop helpers"
EtoysMorph "keeps Etoys specific messages"


And then

Morph
BorderedMorph
WorldMorph (PasteUpMorph renamed, methods such as gridding maintained)
PasteUpMorph "empty PasteUpMorph class for compatibility"
EtoysPasteUpMorph "keeps Etoys specific messages"


Another issue not discussed here is that PasteUpMorph includes
WorldMorph functions.

Pharo has separated this. This is an issue which comes up from time to
time. [5] The advantage of keeping them together is that you may have
worlds in worlds. But this discussion is not related to the issue
Etoys refactoring issue.

--Hannes

[5] http://forum.world.st/WorldMorph-subclass-PasteUpMorph-tp4946461p4946465.html

On 10/3/17, H. Hirzel wrote:
> On 10/3/17, Tobias Pape wrote:
>>
>>> On 03.10.2017, at 15:03, Marcel Taeumel 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 :
>>>>
>>>> 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
>>>> >>
>>>> >>
>>>> >
>>>>
>>>
>>
>>
>>
>



Reply | Threaded
Open this post in threaded view
|

Re: MorphicProject subclass: #EtoysProject

Hannes Hirzel
On 10/3/17, Marcel Taeumel <[hidden email]> wrote:
> @Tobias: In the future, we should get the project-specific parts of
> PasteUpMorph extracted into sth. called WorldMorph to be used only as the
> global "desktop thingy" for Morphic projects. The currently mixed state is
> really confusing. If there is other left-over stuff not yet ready for the
> Morph base class (gridding?), we could add an additional "Playfield", too.
> Not sure about the name, though. :)

Yes, I am fine with this.

A comparatively "deep" hierarchy of classes is not a problem as there
are many methods and grouping the different tasks into different
classes (each one a subclass of the other) will help to understand and
maintain the code.

The current PasteUpMorph has a lot of Etoys related functions (Player
related). Just to keep morphs on "slide" or "page" needs a lot less
code.

In an image  I mainly used during a year I had

    PasteUpMorph allInstances size 1721

and
     MorphicModel allSubclasses size 3581  (unused subclasses as the
PasteUpMorph morphs were just used to paste morphs on it. No active
content)

(Note that the SystemBrowser does not show MorphicModel subclasses)

>
> I do not think that it is worth supporting existing code that relies on
> "PasteUpMorph allInstances" to work in its current form. Same for
> "ContextPart allInstances".
>
>
> Best,
> Marcel
> Am 03.10.2017 15:34:25 schrieb H. Hirzel <[hidden email]>:
> What Marcel refers to
>
> Morph
> BorderedMorph
> PasteUpMorph "maintains the current tasks of Background
> images, gridding,
> drag-and-drop helpers"
> EtoysMorph "keeps Etoys specific messages"
>
>
> And then
>
> Morph
> BorderedMorph
> WorldMorph (PasteUpMorph renamed, methods such as gridding maintained)
> PasteUpMorph "empty PasteUpMorph class for compatibility"
> EtoysPasteUpMorph "keeps Etoys specific messages"
>
>
> Another issue not discussed here is that PasteUpMorph includes
> WorldMorph functions.
>
> Pharo has separated this. This is an issue which comes up from time to
> time. [5] The advantage of keeping them together is that you may have
> worlds in worlds. But this discussion is not related to the issue
> Etoys refactoring issue.
>
> --Hannes
>
> [5]
> http://forum.world.st/WorldMorph-subclass-PasteUpMorph-tp4946461p4946465.html
>
> On 10/3/17, H. Hirzel wrote:
>> On 10/3/17, Tobias Pape wrote:
>>>
>>>> On 03.10.2017, at 15:03, Marcel Taeumel 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 :
>>>>>
>>>>> 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
>>>>> >>
>>>>> >>
>>>>> >
>>>>>
>>>>
>>>
>>>
>>>
>>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: MorphicProject subclass: #EtoysProject

Hannes Hirzel
Attached is screen shot which shows over 3000 'empty' MorphicModel
subclasses illustrating the need to have a

    'slide' or 'page' class

with just 'gridding' and 'drag and drop' behaviour. Probably just
above what is currently called 'PasteUpMorph'. It would then contain
gridding and drag and drop behaviour shifted up from PasteUpMorph.



On 10/3/17, H. Hirzel <[hidden email]> wrote:

> On 10/3/17, Marcel Taeumel <[hidden email]> wrote:
>> @Tobias: In the future, we should get the project-specific parts of
>> PasteUpMorph extracted into sth. called WorldMorph to be used only as the
>> global "desktop thingy" for Morphic projects. The currently mixed state
>> is
>> really confusing. If there is other left-over stuff not yet ready for the
>> Morph base class (gridding?), we could add an additional "Playfield",
>> too.
>> Not sure about the name, though. :)
>
> Yes, I am fine with this.
>
> A comparatively "deep" hierarchy of classes is not a problem as there
> are many methods and grouping the different tasks into different
> classes (each one a subclass of the other) will help to understand and
> maintain the code.
>
> The current PasteUpMorph has a lot of Etoys related functions (Player
> related). Just to keep morphs on "slide" or "page" needs a lot less
> code.
>
> In an image  I mainly used during a year I had
>
>     PasteUpMorph allInstances size 1721
>
> and
>      MorphicModel allSubclasses size 3581  (unused subclasses as the
> PasteUpMorph morphs were just used to paste morphs on it. No active
> content)
>
> (Note that the SystemBrowser does not show MorphicModel subclasses)
>
>>
>> I do not think that it is worth supporting existing code that relies on
>> "PasteUpMorph allInstances" to work in its current form. Same for
>> "ContextPart allInstances".
>>
>>
>> Best,
>> Marcel
>> Am 03.10.2017 15:34:25 schrieb H. Hirzel <[hidden email]>:
>> What Marcel refers to
>>
>> Morph
>> BorderedMorph
>> PasteUpMorph "maintains the current tasks of Background
>> images, gridding,
>> drag-and-drop helpers"
>> EtoysMorph "keeps Etoys specific messages"
>>
>>
>> And then
>>
>> Morph
>> BorderedMorph
>> WorldMorph (PasteUpMorph renamed, methods such as gridding maintained)
>> PasteUpMorph "empty PasteUpMorph class for compatibility"
>> EtoysPasteUpMorph "keeps Etoys specific messages"
>>
>>
>> Another issue not discussed here is that PasteUpMorph includes
>> WorldMorph functions.
>>
>> Pharo has separated this. This is an issue which comes up from time to
>> time. [5] The advantage of keeping them together is that you may have
>> worlds in worlds. But this discussion is not related to the issue
>> Etoys refactoring issue.
>>
>> --Hannes
>>
>> [5]
>> http://forum.world.st/WorldMorph-subclass-PasteUpMorph-tp4946461p4946465.html
>>
>> On 10/3/17, H. Hirzel wrote:
>>> On 10/3/17, Tobias Pape wrote:
>>>>
>>>>> On 03.10.2017, at 15:03, Marcel Taeumel 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 :
>>>>>>
>>>>>> 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
>>>>>> >>
>>>>>> >>
>>>>>> >
>>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>



Empty_MorphicModel_subclasses_Screenshot_2017-10-03.png (52K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: MorphicProject subclass: #EtoysProject

Tobias Pape
In reply to this post by Hannes Hirzel

> On 03.10.2017, at 15:17, H. Hirzel <[hidden email]> wrote:
>
> On 10/3/17, Tobias Pape <[hidden email]> wrote:
>>
>>> On 03.10.2017, at 15:03, Marcel Taeumel <[hidden email]> 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?

Comment of PasteUpMorph:

"A morph whose submorphs comprise a paste-up of rectangular subparts which "show through".  Anything called a 'Playfield' is a PasteUpMorph."

etc.

Best regards
        -Tobias

>
>>
>> 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 <[hidden email]>:
>>>>
>>>> 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
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>>
>>
>


Reply | Threaded
Open this post in threaded view
|

Re: MorphicProject subclass: #EtoysProject

Hannes Hirzel
Thank you for the clarification, Tobias.

As noted earlier in the thread the suggestion at the moment is just to subclass

      PasteUpMorph subclass: EtoysPasteUpMorph

and push all the *Etoys related methods down to EtoysPasteUpMorph.

Link to from EtoysProject to  EtoysPasteUpMorph can easily be done in
the initialize method of EtoysProject


MorphicProject
initialize
        "Initialize a new Morphic Project"
        super initialize.
        world := PasteUpMorph newWorldForProject: self.
        self setWorldBackground: true.
        Locale switchToID: CurrentProject localeID.
        Preferences useVectorVocabulary ifTrue: [world installVectorVocabulary]



EtoysProject
initialize
        "Initialize a new Morphic Project"
        super initialize.
        world := EtoysPasteUpMorph newWorldForProject: self.
        self setWorldBackground: true.
        Locale switchToID: CurrentProject localeID.
        Preferences useVectorVocabulary ifTrue: [world installVectorVocabulary]


or maybe better not override the initialize method but asking the
class in MorphicProject


MorphicProject
initialize
        "Initialize a new Morphic Project"
        super initialize.
        world := self class defaultPasteUpMorphClass newWorldForProject: self.
        self setWorldBackground: true.
        Locale switchToID: CurrentProject localeID.
        Preferences useVectorVocabulary ifTrue: [world installVectorVocabulary]


It depends on other issue which have to be done in

EtoysProject initialize




On 10/3/17, Tobias Pape <[hidden email]> wrote:

>
>> On 03.10.2017, at 15:17, H. Hirzel <[hidden email]> wrote:
>>
>> On 10/3/17, Tobias Pape <[hidden email]> wrote:
>>>
>>>> On 03.10.2017, at 15:03, Marcel Taeumel <[hidden email]> 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?
>
> Comment of PasteUpMorph:
>
> "A morph whose submorphs comprise a paste-up of rectangular subparts which
> "show through".  Anything called a 'Playfield' is a PasteUpMorph."
>
> etc.
>
> Best regards
> -Tobias
>>
>>>
>>> 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 <[hidden email]>:
>>>>>
>>>>> 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
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: MorphicProject subclass: #EtoysProject

David T. Lewis
I put my initial change set on SqueakSource at http://www.squeaksource.com/EtoysProject.

This is intended as a temporary SqueakSource project for working out how
to structure EtoysProject and get it to open a new project with the familiar
playfield.

Hannes, Tobias, Bert and I have write access, and I would like to add Marcel
if he has a squeaksource.com account (I could not find it). Please commit
anything that you thimk makes sense.

As you may have guessed by now, I do not actually know enough about Etoys
to make it work. I just put that change set out to see if I could Tom Sawyer
a few of the more knowledgable folks to doing the hard parts. I think it
might be working :-)

I think that the Etoys package in trunk is probably too large for us to be
doing a lot of experimental changes right now, so my hope is that by putting
the Project related part into its own package temporarily, and putting that
up on squeaksource.com, that we can get this part working well enough
to merge back into Etoys in trunk when it is ready.

From my point of view, "working well enough" means:

- Open a new EtoysProject in Trunk, and the result is an Etoys playfield
that is reasonably similar to a stand-alone Etoys image. The new project
should open with the little car driving around, and with tabs and menus
as expected for Etoys.

- Returning from that Etoys project brings you back to a project that
still works. Whatever preferences were established or overridden to make
Etoys work should be restored so that the other projects are not affected.

Dave


On Tue, Oct 03, 2017 at 10:45:12PM +0200, H. Hirzel wrote:

> Thank you for the clarification, Tobias.
>
> As noted earlier in the thread the suggestion at the moment is just to subclass
>
>       PasteUpMorph subclass: EtoysPasteUpMorph
>
> and push all the *Etoys related methods down to EtoysPasteUpMorph.
>
> Link to from EtoysProject to  EtoysPasteUpMorph can easily be done in
> the initialize method of EtoysProject
>
>
> MorphicProject
> initialize
> "Initialize a new Morphic Project"
> super initialize.
> world := PasteUpMorph newWorldForProject: self.
> self setWorldBackground: true.
> Locale switchToID: CurrentProject localeID.
> Preferences useVectorVocabulary ifTrue: [world installVectorVocabulary]
>
>
>
> EtoysProject
> initialize
> "Initialize a new Morphic Project"
> super initialize.
> world := EtoysPasteUpMorph newWorldForProject: self.
> self setWorldBackground: true.
> Locale switchToID: CurrentProject localeID.
> Preferences useVectorVocabulary ifTrue: [world installVectorVocabulary]
>
>
> or maybe better not override the initialize method but asking the
> class in MorphicProject
>
>
> MorphicProject
> initialize
> "Initialize a new Morphic Project"
> super initialize.
> world := self class defaultPasteUpMorphClass newWorldForProject: self.
> self setWorldBackground: true.
> Locale switchToID: CurrentProject localeID.
> Preferences useVectorVocabulary ifTrue: [world installVectorVocabulary]
>
>
> It depends on other issue which have to be done in
>
> EtoysProject initialize
>
>
>
>
> On 10/3/17, Tobias Pape <[hidden email]> wrote:
> >
> >> On 03.10.2017, at 15:17, H. Hirzel <[hidden email]> wrote:
> >>
> >> On 10/3/17, Tobias Pape <[hidden email]> wrote:
> >>>
> >>>> On 03.10.2017, at 15:03, Marcel Taeumel <[hidden email]> 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?
> >
> > Comment of PasteUpMorph:
> >
> > "A morph whose submorphs comprise a paste-up of rectangular subparts which
> > "show through".  Anything called a 'Playfield' is a PasteUpMorph."
> >
> > etc.
> >
> > Best regards
> > -Tobias
> >>
> >>>
> >>> 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 <[hidden email]>:
> >>>>>
> >>>>> 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
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>>
> >>>
> >>
> >
> >
> >
>

Reply | Threaded
Open this post in threaded view
|

Re: MorphicProject subclass: #EtoysProject

marcel.taeumel
Hi Dave,

I just added an account "mt2" ... because "mt" was already taken. :)

Best,
Marcel

Am 04.10.2017 03:29:07 schrieb David T. Lewis <[hidden email]>:

I put my initial change set on SqueakSource at http://www.squeaksource.com/EtoysProject.

This is intended as a temporary SqueakSource project for working out how
to structure EtoysProject and get it to open a new project with the familiar
playfield.

Hannes, Tobias, Bert and I have write access, and I would like to add Marcel
if he has a squeaksource.com account (I could not find it). Please commit
anything that you thimk makes sense.

As you may have guessed by now, I do not actually know enough about Etoys
to make it work. I just put that change set out to see if I could Tom Sawyer
a few of the more knowledgable folks to doing the hard parts. I think it
might be working :-)

I think that the Etoys package in trunk is probably too large for us to be
doing a lot of experimental changes right now, so my hope is that by putting
the Project related part into its own package temporarily, and putting that
up on squeaksource.com, that we can get this part working well enough
to merge back into Etoys in trunk when it is ready.

From my point of view, "working well enough" means:

- Open a new EtoysProject in Trunk, and the result is an Etoys playfield
that is reasonably similar to a stand-alone Etoys image. The new project
should open with the little car driving around, and with tabs and menus
as expected for Etoys.

- Returning from that Etoys project brings you back to a project that
still works. Whatever preferences were established or overridden to make
Etoys work should be restored so that the other projects are not affected.

Dave


On Tue, Oct 03, 2017 at 10:45:12PM +0200, H. Hirzel wrote:
> Thank you for the clarification, Tobias.
>
> As noted earlier in the thread the suggestion at the moment is just to subclass
>
> PasteUpMorph subclass: EtoysPasteUpMorph
>
> and push all the *Etoys related methods down to EtoysPasteUpMorph.
>
> Link to from EtoysProject to EtoysPasteUpMorph can easily be done in
> the initialize method of EtoysProject
>
>
> MorphicProject
> initialize
> "Initialize a new Morphic Project"
> super initialize.
> world := PasteUpMorph newWorldForProject: self.
> self setWorldBackground: true.
> Locale switchToID: CurrentProject localeID.
> Preferences useVectorVocabulary ifTrue: [world installVectorVocabulary]
>
>
>
> EtoysProject
> initialize
> "Initialize a new Morphic Project"
> super initialize.
> world := EtoysPasteUpMorph newWorldForProject: self.
> self setWorldBackground: true.
> Locale switchToID: CurrentProject localeID.
> Preferences useVectorVocabulary ifTrue: [world installVectorVocabulary]
>
>
> or maybe better not override the initialize method but asking the
> class in MorphicProject
>
>
> MorphicProject
> initialize
> "Initialize a new Morphic Project"
> super initialize.
> world := self class defaultPasteUpMorphClass newWorldForProject: self.
> self setWorldBackground: true.
> Locale switchToID: CurrentProject localeID.
> Preferences useVectorVocabulary ifTrue: [world installVectorVocabulary]
>
>
> It depends on other issue which have to be done in
>
> EtoysProject initialize
>
>
>
>
> On 10/3/17, Tobias Pape wrote:
> >
> >> On 03.10.2017, at 15:17, H. Hirzel wrote:
> >>
> >> On 10/3/17, Tobias Pape wrote:
> >>>
> >>>> On 03.10.2017, at 15:03, Marcel Taeumel 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?
> >
> > Comment of PasteUpMorph:
> >
> > "A morph whose submorphs comprise a paste-up of rectangular subparts which
> > "show through". Anything called a 'Playfield' is a PasteUpMorph."
> >
> > etc.
> >
> > Best regards
> > -Tobias
> >>
> >>>
> >>> 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 :
> >>>>>
> >>>>> 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
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>>
> >>>
> >>
> >
> >
> >
>



Reply | Threaded
Open this post in threaded view
|

Re: MorphicProject subclass: #EtoysProject

David T. Lewis
On Wed, Oct 04, 2017 at 08:28:51AM +0200, Marcel Taeumel wrote:
> Hi Dave,
>
> I just added an account "mt2" ... because "mt" was already taken. :)
>

Thanks Marcel,

I added you to the project. I think that the other "mt" is an inactive
account for [hidden email]. I will see if I can change
that account so that you will be able to use your own "mt" for updates.

I will have to try that later because I am leaving for work now and I
don't want to break something on SqueakSource. It does have some bugs
in handling duplicate author initials I think, and someone else is
also using upper-case "MT" which I think has caused problems in the
past.

Dave


Reply | Threaded
Open this post in threaded view
|

Re: MorphicProject subclass: #EtoysProject

Karl Ramberg
In reply to this post by marcel.taeumel
I'm not sure anybody uses Etoys anymore, but PasteUpMorph is very useful in direct manipulation because of it's various layout and event handling options.  It also act as a container of other morphs, with automatic layout, enumeration etc.
I'm sure most of this could be refactored into Morph class or another class. 

Best,
Karl

On Tue, Oct 3, 2017 at 3:03 PM, Marcel Taeumel <[hidden email]> 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.

Best,
Marcel

Am 03.10.2017 14:57:55 schrieb H. Hirzel <[hidden email]>:

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







Reply | Threaded
Open this post in threaded view
|

Re: MorphicProject subclass: #EtoysProject

Hannes Hirzel
PasteUpMorph is useful and the functions have to be maintained.

However adding more functions to Morph does not make sense.

Squeak 6.0a
Morph selectors size  1345
PasteUpMorph selectors size  530

--Hannes

On 10/4/17, karl ramberg <[hidden email]> wrote:

> I'm not sure anybody uses Etoys anymore, but PasteUpMorph is very useful in
> direct manipulation because of it's various layout and event handling
> options.  It also act as a container of other morphs, with automatic
> layout, enumeration etc.
> I'm sure most of this could be refactored into Morph class or another
> class.
>
> Best,
> Karl
>
> On Tue, Oct 3, 2017 at 3:03 PM, Marcel Taeumel <[hidden email]>
> 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.
>>
>> Best,
>> Marcel
>>
>> Am 03.10.2017 14:57:55 schrieb H. Hirzel <[hidden email]>:
>> 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
>> >>
>> >>
>> >
>>
>>
>>
>>
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: MorphicProject subclass: #EtoysProject

Hannes Hirzel
Karl,

So far entering and existing the Etoys project works smoothly.

Load mcz from into current Squeak 6.0a

MCHttpRepository
    location: 'http://www.squeaksource.com/EtoysProject'
    user: ''
    password: ''

The issue is about providing more settings when entering.

Karl, do you want to be added to the list of developers?

--HH

On 10/5/17, H. Hirzel <[hidden email]> wrote:

> PasteUpMorph is useful and the functions have to be maintained.
>
> However adding more functions to Morph does not make sense.
>
> Squeak 6.0a
> Morph selectors size  1345
> PasteUpMorph selectors size  530
>
> --Hannes
>
> On 10/4/17, karl ramberg <[hidden email]> wrote:
>> I'm not sure anybody uses Etoys anymore, but PasteUpMorph is very useful
>> in
>> direct manipulation because of it's various layout and event handling
>> options.  It also act as a container of other morphs, with automatic
>> layout, enumeration etc.
>> I'm sure most of this could be refactored into Morph class or another
>> class.
>>
>> Best,
>> Karl
>>
>> On Tue, Oct 3, 2017 at 3:03 PM, Marcel Taeumel <[hidden email]>
>> 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.
>>>
>>> Best,
>>> Marcel
>>>
>>> Am 03.10.2017 14:57:55 schrieb H. Hirzel <[hidden email]>:
>>> 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
>>> >>
>>> >>
>>> >
>>>
>>>
>>>
>>>
>>>
>>
>



EtoysProject_Screenshot_2017-10-05.png (102K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: MorphicProject subclass: #EtoysProject

David T. Lewis
I'm seeing problems with SqueakSource right now, trying to figure out
what is wrong. So the project may not be accessible right now :-/

Dave


On Thu, Oct 05, 2017 at 01:17:58AM +0200, H. Hirzel wrote:

> Karl,
>
> So far entering and existing the Etoys project works smoothly.
>
> Load mcz from into current Squeak 6.0a
>
> MCHttpRepository
>     location: 'http://www.squeaksource.com/EtoysProject'
>     user: ''
>     password: ''
>
> The issue is about providing more settings when entering.
>
> Karl, do you want to be added to the list of developers?
>
> --HH
>
> On 10/5/17, H. Hirzel <[hidden email]> wrote:
> > PasteUpMorph is useful and the functions have to be maintained.
> >
> > However adding more functions to Morph does not make sense.
> >
> > Squeak 6.0a
> > Morph selectors size  1345
> > PasteUpMorph selectors size  530
> >
> > --Hannes
> >
> > On 10/4/17, karl ramberg <[hidden email]> wrote:
> >> I'm not sure anybody uses Etoys anymore, but PasteUpMorph is very useful
> >> in
> >> direct manipulation because of it's various layout and event handling
> >> options.  It also act as a container of other morphs, with automatic
> >> layout, enumeration etc.
> >> I'm sure most of this could be refactored into Morph class or another
> >> class.
> >>
> >> Best,
> >> Karl
> >>
> >> On Tue, Oct 3, 2017 at 3:03 PM, Marcel Taeumel <[hidden email]>
> >> 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.
> >>>
> >>> Best,
> >>> Marcel
> >>>
> >>> Am 03.10.2017 14:57:55 schrieb H. Hirzel <[hidden email]>:
> >>> 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
> >>> >>
> >>> >>
> >>> >
> >>>
> >>>
> >>>
> >>>
> >>>
> >>
> >


>


Reply | Threaded
Open this post in threaded view
|

Re: MorphicProject subclass: #EtoysProject

Hannes Hirzel
Dave,

Yes, I encounter problems. They might be related to what I just tried to do:

I wanted to save an updated version of Morphic to the ProjectEtoys
repository  but by mistake I tried to commit it to the trunk. As I do
not have commit rights to trunk this prevented me from changing it
inadvertently. Later on I wanted to commit that version to
ProjectEtoys. It did not work.

--Hannes



On 10/5/17, David T. Lewis <[hidden email]> wrote:

> I'm seeing problems with SqueakSource right now, trying to figure out
> what is wrong. So the project may not be accessible right now :-/
>
> Dave
>
>
> On Thu, Oct 05, 2017 at 01:17:58AM +0200, H. Hirzel wrote:
>> Karl,
>>
>> So far entering and existing the Etoys project works smoothly.
>>
>> Load mcz from into current Squeak 6.0a
>>
>> MCHttpRepository
>>     location: 'http://www.squeaksource.com/EtoysProject'
>>     user: ''
>>     password: ''
>>
>> The issue is about providing more settings when entering.
>>
>> Karl, do you want to be added to the list of developers?
>>
>> --HH
>>
>> On 10/5/17, H. Hirzel <[hidden email]> wrote:
>> > PasteUpMorph is useful and the functions have to be maintained.
>> >
>> > However adding more functions to Morph does not make sense.
>> >
>> > Squeak 6.0a
>> > Morph selectors size  1345
>> > PasteUpMorph selectors size  530
>> >
>> > --Hannes
>> >
>> > On 10/4/17, karl ramberg <[hidden email]> wrote:
>> >> I'm not sure anybody uses Etoys anymore, but PasteUpMorph is very
>> >> useful
>> >> in
>> >> direct manipulation because of it's various layout and event handling
>> >> options.  It also act as a container of other morphs, with automatic
>> >> layout, enumeration etc.
>> >> I'm sure most of this could be refactored into Morph class or another
>> >> class.
>> >>
>> >> Best,
>> >> Karl
>> >>
>> >> On Tue, Oct 3, 2017 at 3:03 PM, Marcel Taeumel <[hidden email]>
>> >> 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.
>> >>>
>> >>> Best,
>> >>> Marcel
>> >>>
>> >>> Am 03.10.2017 14:57:55 schrieb H. Hirzel <[hidden email]>:
>> >>> 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
>> >>> >>
>> >>> >>
>> >>> >
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>
>> >
>
>
>>
>
>
>

1234