| mart |
| Plasma |
Without being able to get the menu size it's not possible to
calculate the right values to pass to open() for cases where
we want to bypass QMenu's own positioning behavior. This
enables doing things like "open context menu above panel even
if it would fit below" with QML menus.
I'm not happy with this change, but if we want the result it's
what we gotta do.
| Automatic diff as part of commit; lint not applicable. |
| Automatic diff as part of commit; unit tests not applicable. |
We have this openRelateive thing with "bottom left posed" and what not, shouldn't it have a thing for "have the bottom left corner of the menu be at the top of the parent item"?
I'm not convinced it's worth it. This patch allows writing the same sort of code we already have in ContainmentInterface for context menu placement. If we resort to doing it there then clearly we need it in other places as well.
(And I wrote openRelative ...)
I can't say how this looks in context of the new popup positioning protocol on Wayland etc. though.
Although ... maybe one hack we could do is change the meaning of "TopPosedLeftAlignedPopup" to "bottom edge of menu at top of visualParent" instead of "0,0 of menu at top of visualParent". Marco?
To expand on the updated patch (I wrote a new commit message, but Phab doesn't notice automatically): The TM appears to be the only user of TopPosedLeftAlignedPopup currently, and the new behavior is also in line with the "Popup positioned on the top" docstring for the enum entry.