[squeak-dev] MorphicProject subclass: #EtoysProject
H. Hirzel
hannes.hirzel at gmail.com
Tue Oct 3 20:45:12 UTC 2017
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 <Das.Linux at gmx.de> wrote:
>
>> On 03.10.2017, at 15:17, H. Hirzel <hannes.hirzel at gmail.com> wrote:
>>
>> On 10/3/17, Tobias Pape <Das.Linux at gmx.de> wrote:
>>>
>>>> On 03.10.2017, at 15:03, Marcel Taeumel <marcel.taeumel at hpi.de> wrote:
>>>>
>>>> +1 :)
>>>>
>>>> And then later: Rename PasteUpMorph to WorldMorph, and keep an empty
>>>> PasteUpMorph subclass around for compatibility reasons. So many ideas
>>>> have
>>>> been ported down to Morph class over the past years. New applications
>>>> have
>>>> no reason to ever use other instances of PasteUpMorph.
>>>
>>> -1
>>> Except for Background images, gridding, drag-and-drop helpers, etc.
>>> It should rather be a PlayField (as it comment already states).
>>
>
>
>> PlayField? I do not find a class named 'PlayField' in a current Trunk
>> image.
>> Which class do you mean?
>
> 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 <hannes.hirzel at gmail.com>:
>>>>>
>>>>> On 10/3/17, H. Hirzel wrote:
>>>>>> Dave
>>>>>>
>>>>>> your change set contains the class EtoysProject with
>>>>>>
>>>>>> EtoysProject selectors
>>>>>>
>>>>>> #(#finalEnterActions: #restoreGlobalPreferences #saveGlobalPreferences
>>>>>> #initializeProjectPreferences #configureOnFirstEntry
>>>>>> #finalExitActions:)
>>>>>>
>>>>>> For complete configuration of a EtoysProject it might be necessary to
>>>>>> do
>>>>>>
>>>>>> PasteUpMorph subclass: EtoysPasteUpMorph
>>>>>>
>>>>>> as well. http://wiki.squeak.org/squeak/6461
>>>>>>
>>>>>> Then Etoys related methods may be pushed down to EtoysPasteUpMorph.
>>>>>
>>>>> See screen shot attached.
>>>>>
>>>>>> And probably an Etoys specific subclass of WorldMenu would be fine as
>>>>>> well
>>>>>> http://wiki.squeak.org/squeak/6461
>>>>>>
>>>>>>
>>>>>> there is a test project [2] and some more information about adaptions
>>>>>> needed because of the UI changes in the thread 'Etoys in 2017?' - UI
>>>>>> preferences [3]. And it would be good to have Etoys methods /
>>>>>> configuration separate [4].
>>>>>>
>>>>>> I suggest that you start go ahead and start implementing this while
>>>>>> using a test Etoys project dropped onto the desktop.
>>>>>>
>>>>>> --Hannes
>>>>>>
>>>>>>
>>>>>> [2] > You simply drop it in. E.g. download this project
>>>>>>> http://etoys.laptop.org/src/Content/ExampleEtoys/CarAndPen.014.pr
>>>>>>
>>>>>> [3] Hannes Hirzel, 'Etoys in 2017?' mail, Wed, Feb 22, 2017 at 11:01
>>>>>> AM
>>>>>>
>>>>>>
>>>>>> [4] David T. Lewis, Sep 4, 2016 at 3:34 PM
>>>>>> "I think it would be great if both Etoys and Scratch were easily
>>>>>> loadable and unloadable in trunk."
>>>>>>
>>>>>> On 10/2/17, David T. Lewis wrote:
>>>>>>> An EtoysProject is a project that is configured for running Etoys. On
>>>>>>> first entry to a new EtoysProject, the playground and project
>>>>>>> preferences
>>>>>>> are initialized to provide an environment similar to that of a
>>>>>>> traditional
>>>>>>> standalone Etoys image.
>>>>>>>
>>>>>>> Certain preferences that are required for Etoys are initialized on
>>>>>>> project
>>>>>>> entry, overriding their global preference values while this
>>>>>>> EtoysProject
>>>>>>> is active. On leaving the project, these preferences are restored to
>>>>>>> their
>>>>>>> previous values.
>>>>>>>
>>>>>>> "ProjectViewMorph openOn: EtoysProject new"
>>>>>>>
>>>>>>> Change set attached for a minimal implementation.
>>>>>>>
>>>>>>> Anyone with Etoys knowledge care to help? I do not know enough about
>>>>>>> Etoys
>>>>>>> to fill in the rest of the initialization that will be required, but
>>>>>>> it
>>>>>>> should not be hard to do.
>>>>>>>
>>>>>>> Dave
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>
>
>
>
More information about the Squeak-dev
mailing list
|