[squeak-dev] SystemWindow positiioning question
marcel.taeumel at hpi.de
Thu Sep 28 06:32:57 UTC 2017
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. ;-)
Am 28.09.2017 04:26:08 schrieb David T. Lewis <lewis at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Squeak-dev