<body><div id="__MailbirdStyleContent" style="font-size: 12pt;font-family: calibri;color: #000000">
To better understand the dynamically-scoped ActiveWorld global, see:<div><br></div><div>HandMorph >> #sendEvent:focus:clear:</div><div>Morph >> #processEvent:</div><div>PasteUpMorph >> #processEvent:using:</div><div><br></div><div>...and I just found a bug in Morph >> #processFocusEvent:using: ... :-D It omits to set the proper (inner) ActiveWorld. Uhhh... have to think about that in the context of event bubbling... *hmpf*</div><div><br></div><div>Best,</div><div>Marcel</div><div class="mb_sig"></div><blockquote class="history_container" type="cite" style="border-left-style:solid;border-width:1px; margin-top:20px; margin-left:0px;padding-left:10px;">
<p style="color: #AAAAAA; margin-top: 10px;">Am 14.11.2017 11:13:23 schrieb H. Hirzel <hannes.hirzel@gmail.com>:</p>I now understand that<br><br>In our current use of Morphic (14th Nov 2017), there is no difference<br>between"World" and "ActiveWorld".<br><br>In the Squeak 2.0 release (and maybe later?), "World" was the<br>outermost world and "ActiveWorld" was the world that is involved in<br>the particular event dispatch (see ActiveEvent, too), which could be<br>in a window, for example.<br><br><br>This means that everyday debugging, one should use "ActiveWorld"<br>instead of "World".<br><br>And it would be good to get "worlds in worlds" working again.<br><br><br>This means that there is or was some code somewhere like<br><br><br> theCurrentOutmostPasteUpMorphAndContainedPasteUpMorphs do:<br> [: pmorph |<br><br> ActiveWorld:= pmorph.<br><br> "process events for ActiveWorld"<br> ]<br><br>--Hannes<br><br>On 11/14/17, H. Hirzel <hannes.hirzel@gmail.com> wrote:<br>> Marcel<br>><br>> you mean that<br>><br>><br>> Object>>currentWorld<br>> "Answer a morphic world that is the current UI focus."<br>> ^ActiveWorld ifNil:[World]<br>><br>> should be maintained? First checking is there is an object<br>> (aPasteUpMorph) pointed to by ActiveWorld and if not set then give<br>> back the object pointed to by World.<br>><br>><br>> Could you please elaborate on this?<br>><br>><br>> --Hannes<br>><br>><br>> On 11/14/17, Marcel Taeumel <marcel.taeumel@hpi.de> wrote:<br>>> Nope. We have to try "ActiveWorld" first. Then fall back to "Project<br>>> current<br>>> world". It is important for event handling code.<br>>><br>>> Best,<br>>> Marcel<br>>> Am 14.11.2017 04:57:02 schrieb David T. Lewis <lewis@mail.msen.com>:<br>>> I want to pause before proceeding too far with removing references to<br>>> global World, and note this:<br>>><br>>> We currently have the globals World and ActiveWorld, as well as the<br>>> following method:<br>>><br>>> Object>>currentWorld<br>>> "Answer a morphic world that is the current UI focus."<br>>> ^ActiveWorld ifNil:[World]<br>>><br>>> The comment for #currentWorld describes what I believe to be the<br>>> functional<br>>> definition of "World" as currently implemented in Squeak projects.<br>>><br>>> It that is the case, then #currentWorld could be implemented as<br>>><br>>> Object>>currentWorld<br>>> "Answer a morphic world that is the current UI focus."<br>>> ^Project current world<br>>><br>>> My assumption is that World and CurrentWorld refer to essentially<br>>> the same thing, except when transitioning from one active Project<br>>> to another, or when implementing WorldInWorlds (see Etoys) or when<br>>> experimenting with running a Project in the background (various old<br>>> experiments circa 2000 or so).<br>>><br>>> Does that sound right?<br>>><br>>> Dave<br>>><br>>><br>>> On Sun, Nov 12, 2017 at 05:12:13PM +0100, Marcel Taeumel wrote:<br>>>> Yay! :-) +1<br>>>><br>>>> If we keep on working to reduce the use of globals, we will be having<br>>>> more<br>>>> fun in the future with extensibility and reuse. :-)<br>>>><br>>>> If one gets a debugger with "nil" after "self world", one should take a<br>>>> deep breath and figure out why that morph a) needs a world or b) doesn't<br>>>> yet have one. Access to globals should only be the last resort then.<br>>>> Like<br>>>> with other dubious "ifNil"-checks: figure out the circumstances, and try<br>>>> to understand the domain better, and keep the code readable. ??<br>>>><br>>>> Best,<br>>>> Marcel<br>>>> Am 12.11.2017 17:05:35 schrieb David T. Lewis :<br>>>> Indeed, that was my concern with respect to correctness.<br>>>><br>>>> Morph>>world<br>>>> ^owner isNil ifTrue: [nil] ifFalse: [owner world]<br>>>><br>>>><br>>>> Nevertheless, I have updated the two inbox packages to use "self world"<br>>>> in<br>>>> morph methods instead of "Project current world". We can easily switch<br>>>> it<br>>>> back if it seems dangerous.<br>>>><br>>>> Dave<br>>>><br>>>> On Sun, Nov 12, 2017 at 10:54:19AM -0500, Bob Arning wrote:<br>>>> > One caveat is that "self world" for a Morph will answer nil if the<br>>>> > morph<br>>>> > is not currently *in* a world.<br>>>> ><br>>>> ><br>>>> > On 11/12/17 10:11 AM, David T. Lewis wrote:<br>>>> > >The "self world" expression works for morphs, and certainly it is<br>>>> > > easier to read.<br>>>> > >It may be somewhat slower, although that would not be a concern in<br>>>> > > most<br>>>> > >usages.<br>>>> > ><br>>>> > >My main concern is correctness, because failures in this area can<br>>>> > > hang<br>>>> > > up the<br>>>> > >UI entirely, and errors are difficult to debug.<br>>>> > ><br>>>> > >When transitioning from one project to another the World variable is<br>>>> > > set to<br>>>> > >the new project's world in #finalEnterActions:. Thus the World global<br>>>> > > is a<br>>>> > >shortcut reference to the world of the current project, and that is<br>>>> > > what<br>>>> > >leads me to suggest the expression "Project current world".<br>>>> ><br>>>><br>>>><br>>>><br>>><br>>>><br>>><br>>><br>>><br>><br><br></lewis@mail.msen.com></marcel.taeumel@hpi.de></hannes.hirzel@gmail.com>
</blockquote>
</div></body>