on xenial help sign in
Remove the async from ScopeListView delegates

ScopeListView already loads delegates async when appropiate so no need to introduce another async layer that introduces sizing problems With the double async it may happen what while we are scrolling down we reach to a point where given the size of the just created delegate with loader not yet loaded (which will be very close to 0) we are already "at the end" of the list, but then a few milliseconds later the loader finishes loading and we could have kept scrolling. This is specially visible at the end of the list where you realize that scrolling ended a bit before the end of the list but the speed of the flicking was good to reach the end By not having the second async we get a better sizing when the delegate is created and things work better

commit6c75c2e7c1ec12da33c0a94a0a873b48fa2b650b authorAlbert Astals <albert.astals@canonical.com> dateMon 1 Jul 2013, 09:56 (13 years ago) parent6ea3dba
4 files changed−4
Dash/DashApps.qml−1 Dash/DashHome.qml−1 Dash/DashMusic.qml−1 Dash/DashVideos.qml−1
Dash/DashApps.qml−1
@@ -150,7 +150,6 @@ ScopeView {
150150 item.model = categoryModels[modelName]
151151 }
152152 }
153− asynchronous: true
154153 }
155154
156155 ListView.onRemove: SequentialAnimation {
Dash/DashHome.qml−1
@@ -161,7 +161,6 @@ ScopeView {
161161 item.clicked.connect(playVideo);
162162 }
163163 }
164− asynchronous: true
165164 }
166165 }
167166
Dash/DashMusic.qml−1
@@ -84,7 +84,6 @@ ScopeView {
8484 onLoaded: {
8585 item.model = results
8686 }
87− asynchronous: true
8887 }
8988 }
9089
Dash/DashVideos.qml−1
@@ -119,7 +119,6 @@ ScopeView {
119119 onLoaded: {
120120 item.model = results
121121 }
122− asynchronous: true
123122
124123 Connections {
125124 target: loader.item