(apologies if this goes through twice; SMTP these days is devolving back towards UUCP with all the explicit routing)
Trygve Reenskaug trygver@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
squeak-dev@lists.squeakfoundation.org