If what you are seeing is bad behavior when moving a SystemWindow, but reasonable behavior when moving an ordinary Morph, then the answer might lie in SystemWindow>>justDroppedInto:event:. The initial focus for world-in-world was not really SystemWindows, but the kind of things one would see in Etoys.

On Sat, Nov 25, 2017 at 04:09:12PM +0100, H. Hirzel wrote:

On 11/16/17, tim Rowledge <tim@rowledge.org> wrote:

On 15-11-2017, at 6:45 PM, David T. Lewis <lewis@mail.msen.com> wrote:

It certainly is nice to be able to rotate the world 30 degrees off its
axis
and still have it remain functional.

Indeed - you have no idea how often I???ve longed for this???


tim

... The most useful feature is  that you can easily move objects in
and out of the subproject to the parent project.

But something is wrong with the way this is working. The symptoms are
that if I do ENTER ACTIVE to activate the project morph as a world-in-world,
and then move or resize windows within that activated world, the geometry
is all wrong, and it seems to be derived from the geometry of the main world
(for the full display).

When the mouse pointer moves over the activated world-in-world, is it
the case that the current project, world, and hand should be changed
to that of the world-in-world? That is not happening, and I suspect it
is at the root of the geometry problem.

I am guessing that there needs to be some hook to update the current
project to that of the world-in-world project whenever the mouse pointer
is over that project.

I know that I am not saying this very clearly but maybe it will trigger
an idea from someone who is familiar with this.

Dave