Skip to content

Support shared thumbnails from remote locations

chrysn requested to merge chrysn/thunar:remote-thumbnails into master

Depends-On: libxfce4util!21

Closes: #636

This follows the plan set out in #21. Names used across compilation units were changed to reflect the altered semantics (thunar_file_get_thumbnail_path to thunar_file_get_thumbnail_uri); internal member and variable names were kept to keep churn in check.

The check for borders was already outdated (with G_DIR_SEPARATOR_S used inconsistently, and no consideration for the still supported legacy case of ~/.thumbnails or the new .sh_thumbnails/) and updated to catch more broadly. (It's more lax now, but I think that if something is seriously named thumbnails/, it's not a common named icon, and the thumbnail border is kind of justified if it's in the path).

Two aspects I find particularly worth pointing out:

  • The pixbuf loading may now access the network. Given that it previously loaded blockingly from disk, I presume that this is running in a sufficiently decoupled thread (but I lack the big picture here).
  • In the sh_thumbnails case, the result of thunar_file_get_thumbnail_uri is not checked to exist any more. (For comparison, in !149 (closed) which would be obsoleted by this, I pointed out that checking property to remove another access). I think that it's generally good to do less checking here, as there either is no file (then the thumbnail display will fail later when attempting to load it) or there is one (and the check is redundant) -- in the end, one syscall (or network activity) suffices to make the determination for shared thumbnails which are the last item in the fallback chain. But again, I may be lacking the bigger picture.

On the organizational side, as this depends on a libxfce4util update, this will probably also need a dependency bump somewhere; not doing that for sake of testability and because there's no released version that contains libxfce4util!21 yet.

Merge request reports