How does the hand transit worlds - what world does it belong to - when 
does it change?
Is the hand's world just whatever ActiveWorld is?


On Saturday, August 16, 2003, at 07:09  AM, Andreas Raab wrote:

> Hi Guys,
>
> This is effectively a rant which was triggered by the recent 
> modifications
> to morph removals. Some of you may remember that we had a bit of 
> trouble
> with morph dropping which was caused by morphs which were "out of the
> world". This triggered a line of thought which I had a couple of times
> before, and I would like to get some feedback on it.
>
> Disclaimer: THIS IS NOT A PROPOSAL TO ACTUALLY CHANGE ANYTHING! I am 
> merely
> interested in getting feedback on the general design idea, so please 
> refrain
> from sending messages like "this would break everything". I know it 
> would
> and I am not proposing to change things - all I am interested in is 
> feedback
> on the general idea.
>
> When we are in Morphic we generally assume that there is some "world"
> describing the overall context of some Morphic environment. Let's 
> ignore the
> particular idiosyncraties of worlds for the moment (such as world 
> state,
> stepping etc) and let's just presume that the world is some container 
> that
> effectively denotes the root of some morphic tree.
>
> Once we start working with pretty much any morph "for real" we 
> basically
> always assume that the morph has some associated "home" (the world) 
> which
> defines the environment. However, these days we cannot always 
> associate a
> morph with its world since the morph may have no immediate association 
> with
> its environment through its owner chain. In those situations we fall 
> back on
> the notion of the "active world" which is provided implicitly. However,
> assuming that there is no single unique world (such as when dealing 
> with
> embedded worlds) we have often significant trouble to determine the
> "correct" environment implicitly. The various heuristics we use today 
> (such
> as changing the "active world" in event handling or stepping methods) 
> work
> sort of but generally they're not very reliable. In addition, the 
> current
> methods for adding and removing morphs can introduce spurious 
> informations
> about when a morph "leaves" a world and when it "enters" another world 
> (such
> as when using "self removeMorph: aMorph; addMorph: aMorph").
>
> It seems to me that the environment (the world) associated with some 
> morph
> is really an ambient property which _should_ be carried along with the 
> morph
> until we really get rid of it. In addtion, in various situations it 
> would be
> tremendously helpful if we could really identify if a morph were 
> crossing
> "world boundaries" or whether we're just moving some guy around.
>
> One way to get rid of the implicit notion of the "active world" would 
> be to
> define that a morph is ALWAYS in some world, unless it has been 
> "destroyed"
> by an interaction or command which clearly denotes that we're not 
> intending
> to use this guy ever again. The way in which the world could be 
> associated
> with some morph might be that the "owner" of some morph cannot ever be 
> nil
> unless that morph has been destroyed. So the owner chain would uniquely
> identify which world a morph is in, and the submorphs of some morph 
> would
> identify that the morph itself is "present" in this particular 
> arrangement
> (regardless of whether the container is present in the arrangement of 
> its
> own container).
>
> In my understanding, this could allow a variety of important 
> mechanisms to
> work very nicely and smoothly. For example, consider something like an 
> #open
> or #close message. What would it mean? It would effectively be 
> equivalent to
> something like setting the morph visible, except that the context in 
> which
> it happens is preserved. E.g., in a PLM you might do something like:
>
> hideScrollbar
> 	scrollBar close. "get rid of it"
>
> showScrollbar
> 	scrollBar open. "open it again in the container it used to be in"
>
> and, finally,
>
> destroyScrollbar
> 	scrollBar destroy. "we would NOT be able to #open it again"
>
> The problem of being inable to associate a world uniquely with some 
> morph
> has already created a large number of hacks where we use pretty weird
> combinations of "trying to find a world" for some object such as:
>
> doSomethingWith: aMorph
> 	| aWorld |
> 	aWorld := aMorph world.
> 	aWorld ifNil:[aWorld := self world].
> 	aWorld ifNil:[aWorld := ActiveWorld].
>
> etc. It seems to me that many of the problems which are associated 
> with the
> inability to refer uniquely to some world _could_ be solved merely by 
> having
> a mechanism like the above. While it does present its own difficulties
> (which I am very aware about; for example invalidations would need to 
> check
> if the morph is actually "present") it seems that conceptually such a 
> model
> would be much clearer than what we have today.
>
> What I am mostly interested in here is: Does anyone see a significant
> conceptual problem in the above? I don't _think_ I am overlooking 
> anything
> important here but I'm interested in what other people think about an
> approach like this.
>
> Cheers,
>   - Andreas
>
>