Could support for the Freedesktop.org Thumbnail specification be added? about xfiles HOT 4 OPEN

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)

from xfiles.

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.

from xfiles.

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.

from xfiles.

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

from xfiles.