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 at rowledge.org> wrote:
>>>> On 15-11-2017, at 6:45 PM, David T. Lewis <lewis at 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
>   
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20171125/2917a7d8/attachment.html>