Open xplshn opened 1 month ago
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)
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.
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.
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
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
andtoybox
, runs withash
(busybox) andksh93
in POSIX mode, didn't test withtoysh
because it strives for completebash
compability)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
usesxpm
files.