(apologies if this goes through twice; SMTP these days is devolving back
towards UUCP with all the explicit routing)

Trygve Reenskaug <trygver at ifi.uio.no> wrote:
> The conclusion is that there is indeed a single input process. But the openInHand mechanism can only be understood by considering the stack. There is no way I can wait until morph has been positioned, because the positioning only starts after I have returned.
> 
> This very cool software leaves me cold. Since I do not want to do other things before the positioning completes, I replace it with a simple and transparent mechanism a la Rectangle>>fromUser

The problem is that while that method is running, Morphic freezes, which
is exactly the reason that the more complex approach is being used.  The
issue is: even though *you* do not have anything useful to do until the
morph is placed, the rest of the system might be doing things.

It's a deep issue.  Morphic's approach means that you cannot write the
sequential code you are trying for.  There are no (safe) "wait"
operations in Morphic.

But actually, there are no safe wait's even in principle.  While you
sleep, all kinds of things can have happened in the image at large.  As
a simple example, it is entirely possible that some morph emptied the
hand.  Perhaps the user tossed the item into the trash.  Because of
possibilities like these, whenever you regain control after letting the
general UI execute, you need to check up on all the relevant state of
the world before continuing.

I suspect that it is actually simpler to avoid the waits, even if you
had them.  In the end, you need to consider that anything might happen
each time you give control back to the general system, and thus you must
ultimately consider your computation as a sequence of little bits of
code that happen between the UI events.  That is, when you are ready to
get your code working really well, then you end up chopping it all up
into little event handlers anyway, and any place you forget to do so is
a hidden source of bugs.  Wait's make it easy to overlook world-changing
activity, while chopping the code into event handlers makes it natural.

But yes, having to immediately chop up the code is harsh when there is
something "simple" you have in mind.  I just don't see a good way around
it.  In the long term, maybe we should find a way to make these
seemingly simple things actually *be* simple--which they aren't right
now, since the world can change under your feat--but short of such an
invention Morphic seems to be set up correctly. 


-Lex