[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