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
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