Merge lp:~jamesh/gallery-app/thumbnail-mtime into lp:gallery-app
| Status: | Merged |
|---|---|
| Approved by: | Arthur Mello on 2015-12-10 |
| Approved revision: | 1236 |
| Merged at revision: | 1257 |
| Proposed branch: | lp:~jamesh/gallery-app/thumbnail-mtime |
| Merge into: | lp:gallery-app |
| Diff against target: |
176 lines (+30/-39) 6 files modified
rc/qml/AlbumViewer/AlbumInternals/FramePortrait.qml (+2/-18) rc/qml/Components/MediaGrid.qml (+1/-10) rc/qml/MediaViewer/MediaViewer.qml (+4/-1) rc/qml/OrganicView/OrganicMediaList.qml (+1/-10) src/media/media-source.cpp (+18/-0) src/media/media-source.h (+4/-0) |
| To merge this branch: | bzr merge lp:~jamesh/gallery-app/thumbnail-mtime |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Arthur Mello (community) | 2015-08-17 | Approve on 2015-12-10 | |
| PS Jenkins bot | continuous-integration | Needs Fixing on 2015-12-01 | |
|
Review via email:
|
|||
Commit Message
Use the file's last modified date for the "at" parameter when invoking the thumbnailer to avoid needlessly reloading thumbnails.
Description of the Change
Currently gallery-app appends an "?at=" parameter to the image:/
At the moment it sets this parameter to Date.now(), which achieves this goal but also results in the thumbnail being reloaded when the file _hasn't_ been changed. What we really want is something that will change when the files contents change. The file's mtime is an obvious candidate here, so that's what I've done here:
1. Add a "lastModified" property to the MediaSource object.
2. set the "at" parameter to mediaSource.
3. Remove the onDataChanged signal connections in the QML, since I've set the dataChanged signal as the notifier for the lastModified property.
| Arthur Mello (artmello) wrote : | # |
Thanks a lot for looking on that. I found one functional issue when testing it on krillin (r99):
1. Open one photo from "Events" tab;
2. Start editing it and crop the image;
3. Return to the opened photo and confirm it was cropped;
4. Return to the "Events" tab.
Expected result:
The thumbnail is updated with the new cropped image.
Current result:
The thumbnail is not updated.
See that I am not moving the event list and so the thumbnail keeps in the visible area all the time. If I move the event list in a way that the thumbnail leaves the visible area it is correctly refreshed when I return to it.
- 1235. By James Henstridge on 2015-08-18
-
Refresh the FileInfo before emitting dataChanged() so the new
modification time is seen.
| James Henstridge (jamesh) wrote : | # |
I think I've got this working now. I've added a refresh() call that clears the cache of the QFileInfo embedded in the MediaSource object, and called it prior to emitting the signal.
| PS Jenkins bot (ps-jenkins) wrote : | # |
FAILED: Continuous integration, rev:1235
http://
Executed test runs:
SUCCESS: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
UNSTABLE: http://
UNSTABLE: http://
SUCCESS: http://
SUCCESS: http://
Click here to trigger a rebuild:
http://
| Arthur Mello (artmello) wrote : | # |
Sorry for the long time without a review. Once again, thx for your work on this. It is definitely a improve from the previous review. But I am seeing on issue while testing:
Steps:
1. Take a couple of photos with camera-app;
2. Open gallery-app and confirm that taken photos are visible;
3. Click one photo to start navigating between them;
4. Edit one of the photos;
5. Return (top left arrow) to exit editing view;
Expected result:
Return to photo viewer displaying the result of the edited photo
Actual result:
Return to photo viewer displaying another photo of the collection. If I navigate back I can see that the edited photo was correctly modified
- 1236. By James Henstridge on 2015-11-27
-
Merge from trunk
| PS Jenkins bot (ps-jenkins) wrote : | # |
FAILED: Continuous integration, rev:1236
http://
Executed test runs:
SUCCESS: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
UNSTABLE: http://
UNSTABLE: http://
SUCCESS: http://
SUCCESS: http://
Click here to trigger a rebuild:
http://
| James Henstridge (jamesh) wrote : | # |
Sorry for not getting back to you on this. I did manage to reproduce your finding, but it wasn't consistent: sometimes it would advance to the next photo and other times it wasn't. So that sounds like a race condition.
I tried instrumenting the QML side code and don't see the view index being changed from that side.
At this point, my guess is that you're seeing a pre-existing race condition. I see that the code is using QFileSystemWatcher to track file system changes, and this feeds into the QAbstractListModel. If an item is being removed then added, this could presumably cause the view index to move forward (i.e. row 2 deleted, causing view to point at new row 2. New row inserted between rows 1 and 2 causes index to move forward to 3).
My patch doesn't even touch this code, so I don't know how it could be responsible for this.
| Arthur Mello (artmello) wrote : | # |
Issue mentioned above does happen on gallery trunk and is probably not related with this MR, bug #1524973 was created to track this issue.
Thanks a lot for looking at this.

FAILED: Continuous integration, rev:1234 jenkins. qa.ubuntu. com/job/ gallery- app-ci/ 1175/ jenkins. qa.ubuntu. com/job/ gallery- app-vivid- amd64-ci/ 103 jenkins. qa.ubuntu. com/job/ gallery- app-vivid- armhf-ci/ 103 jenkins. qa.ubuntu. com/job/ gallery- app-vivid- armhf-ci/ 103/artifact/ work/output/ *zip*/output. zip jenkins. qa.ubuntu. com/job/ gallery- app-vivid- i386-ci/ 103 jenkins. qa.ubuntu. com/job/ generic- click-autopilot -vivid- touch/256 jenkins. qa.ubuntu. com/job/ generic- click-autopilot -runner- mako/908 jenkins. qa.ubuntu. com/job/ generic- click-builder- vivid-armhf/ 722 s-jenkins. ubuntu- ci:8080/ job/touch- flash-device/ 22609
http://
Executed test runs:
SUCCESS: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
UNSTABLE: http://
UNSTABLE: http://
SUCCESS: http://
SUCCESS: http://
Click here to trigger a rebuild: s-jenkins. ubuntu- ci:8080/ job/gallery- app-ci/ 1175/rebuild
http://