Bug 422289 - First delegate of ListView within OverlaySheet it's initially drawn at wrong position
Summary: First delegate of ListView within OverlaySheet it's initially drawn at wrong ...
Status: CONFIRMED
Alias: None
Product: frameworks-kirigami
Classification: Frameworks and Libraries
Component: general (show other bugs)
Version: Master
Platform: Other Linux
: NOR normal
Target Milestone: Not decided
Assignee: Marco Martin
URL:
Keywords:
: 435546 (view as bug list)
Depends on:
Blocks:
 
Reported: 2020-05-31 10:20 UTC by Ismael Asensio
Modified: 2022-01-07 14:05 UTC (History)
7 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
QML test sample to reproduce the bug (1.40 KB, text/x-qml)
2020-05-31 10:20 UTC, Ismael Asensio
Details
affected GHNS window (213.23 KB, image/png)
2020-11-24 12:18 UTC, Patrick Silva
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Ismael Asensio 2020-05-31 10:20:09 UTC
Created attachment 128949 [details]
QML test sample to reproduce the bug

SUMMARY

When a Kirigami.OverlaySheet contains a ListView with section headers, 
the first delegate gets assigned a position of (0,0), and gets hidden 
behind the header.

It only re-positions when the delegate is destroyed and re-created, 
for example, when a filter changes the model. 
Calling `forceLayout()` or other signals do not fix it. 

STEPS TO REPRODUCE
Attached qml test case.

OBSERVED RESULT
https://invent.kde.org/plasma/kwin/uploads/e6d2f52edd24f9140cc2937bb5f89496/Screenshot_20200530_150309.png
https://invent.kde.org/plasma/kwin/uploads/6f426384d6114fe680bc88c04551e6cd/delegate_wrong.mp4

EXPECTED RESULT
https://invent.kde.org/plasma/kwin/uploads/47cd179c09f8c70a9a2e330eb2d16216/delegate_ok.mp4

SOFTWARE/OS VERSIONS
Operating System: Kubuntu 20.04
KDE Plasma Version: 5.19.80
KDE Frameworks Version: 5.71.0
Qt Version: 5.14.2

ADDITIONAL INFORMATION
Specific case in kcm/kwinrules: BUG 421583
See: https://invent.kde.org/plasma/kwin/-/merge_requests/37
Comment 1 David Edmundson 2020-05-31 13:29:33 UTC
I found where the bug is. This patch:

Kirigami
--- a/src/controls/templates/AbstractListItem.qml
+++ b/src/controls/templates/AbstractListItem.qml
@@ -143,7 +143,7 @@ T2.ItemDelegate {
 
     opacity: enabled ? 1 : 0.6
 
-    height: visible ? implicitHeight : 0
+    height: implicitHeight
 

"fixes" it. 

visible is false when the view is initially created and updating it doesn't do the relayout

I don't know if that last part is a sign of a QtQuick bug or one our side.
Comment 2 Marco Martin 2020-06-30 15:06:15 UTC
meh, even a forceLayout() on the view after visible change doesn't help
Comment 3 Marco Martin 2020-06-30 15:06:51 UTC
maybe should just forget about it tho i'm not sure how many apps this behavior change will break, so probably thins shouldn't be done
Comment 4 Ismael Asensio 2020-06-30 22:08:27 UTC
I agree that this "fix" can break other existing apps that relay on non-visible delagates not taking any space (QQC2.ItemDelegate also behaves that way, but I think AbstractListItem does the right thing).

But I think the problem is important enough as not to keep looking for the cause. 
When more and more apps are being migrated to kirigami, it's a matter of time that this will pop-up in more important places.

I wonder why this affects only the first item y-position, and not the rest of them.
Comment 5 Patrick Silva 2020-11-24 12:18:17 UTC
Created attachment 133606 [details]
affected GHNS window

I'm attaching a screenshot showing an affected "get how new stuff" window.

Operating System: Arch Linux
KDE Plasma Version: 5.20.3
KDE Frameworks Version: 5.76.0
Qt Version: 5.15.2
Comment 6 Ismael Asensio 2021-04-26 18:45:08 UTC
*** Bug 435546 has been marked as a duplicate of this bug. ***
Comment 7 bart 2021-06-22 07:14:46 UTC
As already hinted above, a workaround for this issue is to explicitly set the height on the ListSectionHeader, e.g.:

height: implicitHeight