Could support for the Freedesktop.org Thumbnail specification be added?

[xplshn]

I propose support for the Freedesktop.org Thumbnail specification be added, its rather straightforward, it can even be implemented in a SH script, the only thing that would need to be added is a png library and an md5 library, for which I propose https://github.com/Zunawe/md5-c and stb_image.h be used, because they are simple and suckless

https://web.archive.org/web/20230304184025/https://specifications.freedesktop.org/thumbnail-spec/thumbnail-spec-latest.html
https://specifications.freedesktop.org/thumbnail-spec/latest/

This is an example for determining the path of a thumbnail, POSIX SH (works with sbase and toybox, runs with ash (busybox) and ksh93 in POSIX mode, didn't test with toysh because it strives for complete bash compability)

#!/bin/sh

# Function to calculate the MD5 hash of a URI
calculate_md5() {
   if ! printf "%s" "$1" | md5sum | cut -d ' ' -f1; then
        echo "There was an error calculating the MD5 hash. Quitting..."
        exit 1
    fi
    # Return the hash value
    echo "$hash"
}

# Function to determine the correct path to a thumbnail for a file
calc_thumbnail() {
    input_file="$1"
    thumbnail_file="$2"

    # Ensure input file and thumbnail file are specified
    if [ -z "$input_file" ] || [ -z "$thumbnail_file" ]; then
        echo "Usage: $0 [file_to_thumbnail] [128x128thumbnail.png]"
        exit 1
    fi

    # Check if the thumbnail file exists
    if [ ! -f "$thumbnail_file" ]; then
        echo "The thumbnail file does not exist."
        exit 1
    fi

    # Determine the canonical URI of the input file
    abs_path=$(readlink -f "$input_file")
    uri="file://$abs_path"

    # Calculate the MD5 hash of the URI
    hash=$(calculate_md5 "$uri")

    # Determine the target directory and filename for the thumbnail
    thumbnail_dir="${XDG_CACHE_HOME:-$HOME/.cache}/thumbnails/normal"
    thumbnail_path="$thumbnail_dir/$hash.png"

    # Copy the provided thumbnail to the target path
    echo "$thumbnail_file should have its thumb at: $thumbnail_path"
}

# Call the function with arguments
calc_thumbnail "$1" "$2"

The thumbnail xdg specification goes on and on about different sizes for thumbnails, but I don't think you would be interested in adding support for it, even if trivial, because xfiles uses xpm files.

[xplshn]

Another method could be: Support an ENV file that the user can specify, which basically is a command that does the following:
xfiles runs $XFILES_GTHUMBNAIL_PATH $FILE and that commands responds with the correct path to the .png file OR returns 5 if the file doesn't exist and 1 if the script has failed due to other reasons, maybe it can also return 10 when there isn't a handler for a specific extension, so that xfiles doesn't run the cmd again for files of that type during the current running instance. This way, all xfiles needs to do, is add support for that env and provide a script according to the specifications. (I offer myself to do the script, I'm a sucker for POSIX correctness and avoiding external commands as much as possible)

[phillbush]

Hi, I thought on supporting XDG/freedesktop thumbnail spec on the recently added TODO file: https://github.com/phillbush/xfiles/blob/master/TODO#L230

However, I am not sure on the advantages of implementing that. The only kinda pro is that thumbnails could be shared with dolphin/pcmanfm/etc. But is that really needed?

Also, png is compressed. XFiles perform pretty fast on loading thumbnails, and not having to decompress them is a good thing. Compressed thumbnails could save space on disk, but they are so small (64x64) that plain bitmaps make no difference.

[xplshn]

Hi, I thought on supporting XDG/freedesktop thumbnail spec on the recently added TODO file: https://github.com/phillbush/xfiles/blob/master/TODO#L230

However, I am not sure on the advantages of implementing that. The only kinda pro is that thumbnails could be shared with dolphin/pcmanfm/etc. But is that really needed?

Also, png is compressed. XFiles perform pretty fast on loading thumbnails, and not having to decompress them is a good thing. Compressed thumbnails could save space on disk, but they are so small (64x64) that plain bitmaps make no difference.

Can't the loading be done asynchronously? I wanted to add this to support .AppBundles and .AppImages... Another advantage would be; The user's don't need to configure anything, most users will have some kind of thumbnailer already running if they have GTK/QT based programs in their systems, and even if they didn't have one, upon adding a thumbnailer daemon, thumbnails would automatically start working, no config needed.

But I understand if this is not added.

[xplshn]

Also, png is compressed. XFiles perform pretty fast on loading thumbnails, and not having to decompress them is a good thing. Compressed thumbnails could save space on disk, but they are so small (64x64) that plain bitmaps make no difference.

Note, its not compressed, its encoded, the decoding doesn't take too much time tho, using xpm raw is usually slower due to the memory usage/allocation if the file is bigger than 128x128, it also depends on the quality of the png too. If you want to optimize xfiles in a Data-Oriented manner (make this efficient in terms of, data stays in CPU cache, we avoid RAM and system), you should watch this talk about data oriented programming, can't recommend it enough; https://www.youtube.com/watch?v=IroPQ150F6c