<div id="__MailbirdStyleContent" style="font-size: 12pt;font-family: calibri;color: #000000">
Hi, Hannes.<div><br></div><div>In the long term, I would want to get rid of Object >> #currentWorld. For now, we could optimize to:</div><div><br></div><div>Object >> currentWorld</div><div> ^ ActiveWorld ifNil: [Project current world]</div><div><br></div><div>I would move it from the category "macpal" to "*Morphic-Kernel".</div><div><br></div><div>Baby steps. :-)</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;min-width: 500px">
<p style="color: #AAAAAA; margin-top: 10px;">Am 14.11.2017 10:55:43 schrieb H. Hirzel <hannes.hirzel@gmail.com>:</p>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 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 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 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. 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 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 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></lewis@mail.msen.com></marcel.taeumel@hpi.de>
</blockquote></div>