Skip to content

WIP: Tidy up thumnail request logic

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 by Alexander Schwinn

Merge request reports