[squeak-dev] ActiveWorld and World globals (was: The Inbox: Morphic-dtl.1360.mcz)

H. Hirzel hannes.hirzel at gmail.com
Tue Nov 14 10:13:13 UTC 2017


I now understand that

In our current use of Morphic (14th Nov 2017), there is no difference
between"World" and "ActiveWorld".

In the Squeak 2.0 release (and maybe later?), "World" was the
outermost world and "ActiveWorld" was the world that is involved in
the particular event dispatch (see ActiveEvent, too), which could be
in a window, for example.


This means that everyday debugging, one should use "ActiveWorld"
instead of "World".

And it would be good to get "worlds in worlds" working again.


This means that there is or was some code somewhere like


    theCurrentOutmostPasteUpMorphAndContainedPasteUpMorphs  do:
           [: pmorph |

                 ActiveWorld:= pmorph.

                "process events for ActiveWorld"
         ]

--Hannes

On 11/14/17, H. Hirzel <hannes.hirzel at gmail.com> wrote:
> Marcel
>
> you mean that
>
>
>     Object>>currentWorld
>             "Answer a morphic world that is the current UI focus."
>             ^ActiveWorld ifNil:[World]
>
> should be maintained? First checking is there is an object
> (aPasteUpMorph) pointed to by ActiveWorld and if not set then give
> back the object pointed to by World.
>
>
> Could you please elaborate on this?
>
>
> --Hannes
>
>
> On 11/14/17, Marcel Taeumel <marcel.taeumel at hpi.de> wrote:
>> Nope. We have to try "ActiveWorld" first. Then fall back to "Project
>> current
>> world". It is important for event handling code.
>>
>> Best,
>> Marcel
>> Am 14.11.2017 04:57:02 schrieb David T. Lewis <lewis at mail.msen.com>:
>> I want to pause before proceeding too far with removing references to
>> global World, and note this:
>>
>> We currently have the globals World and ActiveWorld, as well as the
>> following method:
>>
>> Object>>currentWorld
>> "Answer a morphic world that is the current UI focus."
>> ^ActiveWorld ifNil:[World]
>>
>> The comment for #currentWorld describes what I believe to be the
>> functional
>> definition of "World" as currently implemented in Squeak projects.
>>
>> It that is the case, then #currentWorld could be implemented as
>>
>> Object>>currentWorld
>> "Answer a morphic world that is the current UI focus."
>> ^Project current world
>>
>> My assumption is that World and CurrentWorld refer to essentially
>> the same thing, except when transitioning from one active Project
>> to another, or when implementing WorldInWorlds (see Etoys) or when
>> experimenting with running a Project in the background (various old
>> experiments circa 2000 or so).
>>
>> Does that sound right?
>>
>> Dave
>>
>>
>> On Sun, Nov 12, 2017 at 05:12:13PM +0100, Marcel Taeumel wrote:
>>> Yay! :-) +1
>>>
>>> If we keep on working to reduce the use of globals, we will be having
>>> more
>>> fun in the future with extensibility and reuse. :-)
>>>
>>> If one gets a debugger with "nil" after "self world", one should take a
>>> deep breath and figure out why that morph a) needs a world or b) doesn't
>>> yet have one. Access to globals should only be the last resort then.
>>> Like
>>> with other dubious "ifNil"-checks: figure out the circumstances, and try
>>> to understand the domain better, and keep the code readable. ??
>>>
>>> Best,
>>> Marcel
>>> Am 12.11.2017 17:05:35 schrieb David T. Lewis :
>>> Indeed, that was my concern with respect to correctness.
>>>
>>> Morph>>world
>>> ^owner isNil ifTrue: [nil] ifFalse: [owner world]
>>>
>>>
>>> Nevertheless, I have updated the two inbox packages to use "self world"
>>> in
>>> morph methods instead of "Project current world". We can easily switch
>>> it
>>> back if it seems dangerous.
>>>
>>> Dave
>>>
>>> On Sun, Nov 12, 2017 at 10:54:19AM -0500, Bob Arning wrote:
>>> > One caveat is that "self world" for a Morph will answer nil if the
>>> > morph
>>> > is not currently *in* a world.
>>> >
>>> >
>>> > On 11/12/17 10:11 AM, David T. Lewis wrote:
>>> > >The "self world" expression works for morphs, and certainly it is
>>> > > easier to read.
>>> > >It may be somewhat slower, although that would not be a concern in
>>> > > most
>>> > >usages.
>>> > >
>>> > >My main concern is correctness, because failures in this area can
>>> > > hang
>>> > > up the
>>> > >UI entirely, and errors are difficult to debug.
>>> > >
>>> > >When transitioning from one project to another the World variable is
>>> > > set to
>>> > >the new project's world in #finalEnterActions:. Thus the World global
>>> > > is a
>>> > >shortcut reference to the world of the current project, and that is
>>> > > what
>>> > >leads me to suggest the expression "Project current world".
>>> >
>>>
>>>
>>>
>>
>>>
>>
>>
>>
>


More information about the Squeak-dev mailing list