Bug 422289

Summary: First delegate of ListView within OverlaySheet it's initially drawn at wrong position
Product: [Frameworks and Libraries] frameworks-kirigami Reporter: Ismael Asensio <isma.af>
Component: generalAssignee: Marco Martin <notmart>
Status: CONFIRMED ---    
Severity: normal CC: 1i5t5.duncan, bart, bugseforuns, isma.af, kde, kwin-bugs-null, nate
Priority: NOR    
Version: Master   
Target Milestone: Not decided   
Platform: Other   
OS: Linux   
Latest Commit: Version Fixed In:
Attachments: QML test sample to reproduce the bug
affected GHNS window

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