Previous logic was
- If parent is a menubar, then position just below the menu item
- If parent is also a popupmenu, then position just to the right
of the menu item
- If the user wants custom placement, they can use popupOffset,
which gets added to the position always
In this commit, we do the following:
If the parent is a menubar, then there are two candidate positions:
just below the menu item (primary), and just above the menu item (secondary)
Check the clipping rectangle of our parent, or if no parent, the root container.
Compute for both positions the minimum shift we need to do from the candidate spot
in order to not be clipped.
If primary requires verticle correction (shift up into menubar) and secondary does
not (so the menubar is near bottom of clipping region) then we use the (corrected)
secondary position, otherwise we use the corrected primary position.
If the parent is a popupmenu, then we do the same thing, but the primary position
is just to the left, and the secondary is just to the right, and we are concerned
about horizontal correction.
We always add "popupOffset" to the result, after these computations have happened.
However this might be bad -- for someone using popupOffset to do fine control,
they might not be happy with the new behavior.
It might be better to
1) Add popupOffset to both the candidate positions first, before doing the clipping
checks. However, this is hard
because IIRC the popupOffset is in unified dimensions, and the candidate positions
are just absolute floating point values. But if we don't do this we might get
bad behavior when both features come into effect.
2) Disable the clipping checks if popupOffset is nonzero -- the argument being,
if the user set a custom offset then they know what they are doing.
3) Add a boolean flag to disable "smart" placement, but make the smart placement
on by default. Then we can be backwards compatible with people who wanted to
have fine-control over the positioning using popupOffset, they can just set
the smart placement to off.