Hi Dave,
in short, take a look at Morph >> #clearArea to honor the Sugar navigation bar.
You can find a longer explanation by navigation the following code snippets:
SystemWindow >> #justDroppedInto:event: SystemWindow >> #assureLabelAreaVisible RealEstateAgent class >> #maximumUsableAreaInWorld: Morph >> #visibleClearArea Morph >> #clearArea
The avoidance of the docking bar on window-drop is new. But the actual logic behind it is very old, from 2004. It has been used for maximizing a window.
To verify, try maximizing your window and see if it also interferes with the Sugar navigation bar.
Maybe the SugarNavigatorBar should respond to #isDockingBar with true. Might do the trick. ;-)
Best, Marcel
Am 28.09.2017 04:26:08 schrieb David T. Lewis lewis@mail.msen.com: When I use the mouse to move a SystemWindow to a new position, the mouse down produces a square frame that moves with the hand position, and the mouse up makes the frame go away with the SystemWindow being relocated to the new position.
In most cases, the new position of the SystemWindow is the position to which it was moved with the mouse. However, if the new position is at the top of the world PasteUpMorph, possibly conflicting with the world main docking bar or the Sugar navigator bar, then the new SystemWindow position is modified to avoid the top region.
Where is the code that figures out the new position in the case of a SystemWindow being dragged to the top of the world PasteUpMorph? I am trying to debug a window positioning problem in one of my images, and I cannot figure out where the magic happens.
Thanks, Dave