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@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@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@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".