https://bugs.kde.org/show_bug.cgi?id=473241
--- Comment #2 from ratijas <m...@ratijas.tk> --- I believe it's a bug in qqc2-desktop-style or QtQuick.Controls, as similar thing occurs in other places as well. I noticed it as early as during ScrollBar rework (that "mega-fix" MR) in January. Basically, some ScrollBar's metrics properties are stalled. They don't notify of their changes, but if you emit them by calling associated signals manually, everything snaps into place. Might be a Qt 6 regression as well. Just look at this comment: > // Note about comma, operator: including visualPosition in this > // expression help it propagate signals when needed; otherwise in > // Qt 6 scrollbar might get stuck being too large, and clip out. > minimum: 0 > maximum: (void controlRoot.visualPosition), > Math.round(length / Math.max(0.001, controlRoot.visualSize) - length) > value: Math.round(length / Math.max(0.001, controlRoot.visualSize) * > Math.min(1 - 0.001, controlRoot.visualPosition)) https://invent.kde.org/frameworks/qqc2-desktop-style/-/blob/f3dd8b22c83f896abfbfd0c03443c4f12e93e08c/org.kde.desktop/ScrollBar.qml#L219-225 Whichever component is at fault here, I bet it's not Kirigami. Unless… ListView/Flickable really fails to recalculate its content height with all those bindings and re-assignments during initialization… in which case it would still be QtQuick's fault. -- You are receiving this mail because: You are watching all bug changes.
