https://bugs.kde.org/show_bug.cgi?id=432194
Harald Sitter <sit...@kde.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |sit...@kde.org
--- Comment #3 from Harald Sitter <sit...@kde.org> ---
Looks like something is going wrong inside popup placement. That being said the
desktop style has the Menu at 0 height until shown once, this may well be why
something is going wrong inside the popup placement. i.e. the first time round
the menuHeight is always -`Kirigami.Units.gridUnit * 3`, which is wrong one way
or the other I guess. The fusion style doesn't have that problem.
>From some tinkering I'd say this could be simplified as per the docs [1]. If
the menu simply was the child of the menubutton, which I suppose has no
downsides since the menu isn't a context menu and thus always attached to the
button, the trigger would simply become
> onPressed: menu.open()
and the position set as a binding, avoiding the problem altogether as the
position would simply update once height is correct.
> Menu { x:0; y: height > 0 ? -height : Kirigami.Units.gridUnit * 3
Anyway. I'm mostly guessing here. Plus, whatever is wrong with our Menu{} style
needs debugging, if fusion doesn't have the Menu at height 0 initially it
stands to reason desktop shouldn't either.
[1] https://doc.qt.io/qt-5/qml-qtquick-controls2-popup.html#popup-positioning
--
You are receiving this mail because:
You are watching all bug changes.
