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 11/25/17 11:08 AM, David T. Lewis wrote:
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