Skip to content
GitLab
Projects Groups Topics Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Register
  • Sign in
  • thunar thunar
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Graph
    • Compare revisions
  • Issues 335
    • Issues 335
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 10
    • Merge requests 10
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Releases
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • XfceXfce
  • thunarthunar
  • Merge requests
  • !184

WIP: Tidy up thumnail request logic

  • Review changes

  • Download
  • Patches
  • Plain diff
Closed Alexander Schwinn requested to merge alexxcons/thunar:#694_shared_thumbnails_do_reload into master Jan 20, 2022
  • Overview 1
  • Commits 5
  • Pipelines 4
  • Changes 5

Fixes #694 (closed)

I started with some refactoring to make stuff better readable. So the first two commits are not realy required for the fix.

One problem was that "thunar_standard_view_schedule_thumbnail_idle", which is triggered on each "thunar_standard_view_reload" did force a thumbnail request for all files which are visible. (no "lazy flag" used = "force") even though many files already might have an up to date thumbnail.

The decision if a "force" needs to be done (e.g. on F5, or if the file monitor found out that a particular file changed), needs to be done in a much more granular way in order to minimize the required thumbnail requests.

If a shared thumbnail is available, "force" will be ignored, since it would generate a local thumbnail, which kindof makles shared thumbnails meaningless, if the intention only was to update the folder.

The logic inside thunar_thumbnailer_begin_job which actually decides wheather a thumbnail should be requested was a bit weird. I just reordert thing in a way which makes sense for me, and to minimize the number of thumbnail requests.

TODO: Currently no thumbnail is force-requested when a file-change was noticed by the file-monitor. (Though f5 already will work to update the thumbnail)

Edited Jan 31, 2022 by Alexander Schwinn
Assignee
Assign to
Reviewers
Request review from
Time tracking
Source branch: #694_shared_thumbnails_do_reload