Supporting shared thumbnail repositories and video update
Supporting shared thumbnail repositories and video updateGreetings! After 84 yea.... 17 days I'm back with another blog-post. This time a shorter one, since most of my work has been on finishing the features that I talked about last week and implementing support for shared thumbnail repositories (as specified in freedesktop.org).
Support for Shared thumbnail repositories: For 15 years the #SHARED part of the freedesktop.org thumbnail specification has been ignored by the vast majority of Linux file managers. At last, the time has come for Thunar to be one of the first, if not the first, file managers that support shared thumbnail repositories. 'What are shared thumbnail repositories' I hear you ask. Let me explain. Imagine that you have a large external hard drive that contains family photos (something that most, if not all of us have). Connecting it in a new PC or as a different user would normally lead to thumbnailing for all the files that are visible in your file manager. That process is both slow and wasting space. That is the problem that shared thumbnail repositories solve. Instead of creating and storing thumbnail in the default location of the PC filesystem, thumbnails are stored locally in the USB/HDD/CD. It is a niche but potentially extremely useful feature.
I've linked a video that showcases the stuff that I've talked about in these blogposts, with the exception of shared thumbnail repositories. Even though the code is complete and it works as it should there has been a problem with Tumbler while refactoring. Specifically, it looks like Tumbler doesn't use libxfce4util, where I placed some shared code to avoid duplication. Hopefully next time I'll be able to show them to you.
Link to all my Merge Requests: link
Previous post
Weekly update
Safety flag
Related: Thunar !121
Coding safety flag interface is done, but since it requires new version of libxfce4util, it is waiting for docker image to be updated.
Keep metadata when copying from remote location
Related: Thunar !127
Thunar loses some metadata on copy when file source is from remote location like ftp://. Right now, I am working on what metadata should be copied in that case.
Use proper name to copy files
Related: Thunar !128
gvfs-gdrive extension provides a neat way to use Google Drive as a network drive, but copied files got an unintelligible name for some reason. So I am patching up the logic to move the files into a readable name.
Safe copy
Related: Thunar !130
This MR will add a feature to separate copy-in-progrss files and already copied files in case something aborts the copy, so “skip all existing files” on the second try can guarantee that every file is copied properly. Without this feature, the user has to copy every file again or somehow find which one is a corrupted file (which is like finding a needle in haystack).
It also will provide optional feature to check every file copied that it is not corrupted - probably used for network drives.
Right now only the first part is done - every files copied will be first named as *.partial~ (which is hidden) and be renamed after copy.