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 <hannes.hirzel at gmail.com> wrote:
> On 10/3/17, Marcel Taeumel <marcel.taeumel at hpi.de> 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 <hannes.hirzel at gmail.com>:
>> 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
>>>>>> >>
>>>>>> >>
>>>>>> >
>>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Empty_MorphicModel_subclasses_Screenshot_2017-10-03.png
Type: image/png
Size: 39337 bytes
Desc: not available
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20171003/fb1722f4/attachment-0001.png>