Fix thumbnail bar update after editing a viewed image

Authored by muhlenpfordt on Mar 26 2018, 1:16 PM.



After editing an image (e.g. rotate) a new thumbnail is created but
it is not repainted in the View Mode thumbnail bar.
The custom signals documentChanged and busyStateChanged provide
a QModelIndex for the modified document but this is based on the
source model and cannot be used in ThumbnailBarView where the list
view is based on a filtered proxy model and the index is wrong or
does not exist in some cases.
This patch uses the QUrl as argument for both signals and gets the
proper index for the current model in the receiver view.

FIXED-IN: 18.04.0

Test Plan
  • Open image in Gwenview View Mode
  • Enable thumbnail bar (Ctrl+B)
  • Edit image (e.g. rotate with Ctrl+R)
  • Edit a second time (same or another image)
  • Thumbnail should always correspond to edited image

Diff Detail

R260 Gwenview
Automatic diff as part of commit; lint not applicable.
Automatic diff as part of commit; unit tests not applicable.
muhlenpfordt requested review of this revision.Mar 26 2018, 1:16 PM
muhlenpfordt created this revision.
  • Updating the thumbnail after the first edit is a side effect of the appearing save bar and therefore changing the view geometry.
  • In Browse Mode the provided QModelIndex and thumbail update is correct since the base model is used here.
  • In fullscreen mode all visible thumbnails in the autohide bar are repainted after the image view is updated so this problem is not noticeable here.
huoni added a subscriber: huoni.Mar 28 2018, 12:41 AM

Patch works well for me.
I'll leave code review for a more experienced dev, though I can't see any obvious issues with it.

rkflx accepted this revision.Apr 7 2018, 10:40 PM
rkflx added a subscriber: rkflx.

I also noticed this problem quite often (there is no Bugzilla entry though, just checked). Thanks for the patch and sorry for the wait! Nice analysis, makes sense to me.

No issues found when testing, and patch LGTM. The very long signal-slot chain is a bit weird, but I see no good way to make it simpler, so I guess this is fine.

I'd say this patch and the dependent patch can go to stable, either now for 18.04.0 or later for 18.04.1.

This revision is now accepted and ready to land.Apr 7 2018, 10:40 PM
muhlenpfordt edited the summary of this revision. (Show Details)

Rebase to Applications/18.04

This revision was automatically updated to reflect the committed changes.