XYplorer Beta Club

I searched around the forums a bit and couldn't anything quite like this, so...

It would be neat to have a script command that could specify a second image to use as a surrogate for the thumbnail of another file. As I understand it Xyplorer uses the default windows thumbnail provider system. I additionally use icaros to generate thumbnails for extra formats, but I don't want to necessarily bypass the thumbnail providers. Rather I imagine something simple like this:
setthumbnail(dest, src)
would refresh the thumbnail for the destination file, but instead request the thumbnail for the src file, and save that as the dest's thumbnail in Xyplorer's cache.
The use case is for videos that may use custom thumbnails. Some videos can have thumbnails embedded of course which ideally the provider ought to be able to acquire, but there may be times I want to use an alternative image for my local cache and not modify the original video file, or if the provider just isn't getting the right frame.

Alternatively, if there isn't enough interest to warrant this implementation, is the Xyplorer thumbnail cache file format published anywhere? Thank you.

I like the idea, but setthumbnail(dest, src) without context would be too involved.

a) I could offer setthumbnail(src) to work on the currently selected file (in thumbnails view). You could then pull the src from the clipboard: setthumbnail(<clp>).

b) Here's another idea where the injected thumbnails would even survive refreshes and different qualities and sizes: You provide a file called "XYthumbsMap.txt" in <xydata> that looks like this: Where file1 can be full path, just a filename, or a wildcard pattern to match. So the thumbnail src would be pulled from this map file each time the thumbnail is generated.

Hi Don, with your b) option does that mean you could assign a thumbnail/image to a non-image like a exe or ini file that resides in a folder with images? That would be interesting. It sounds similar to your patch system for icons

Yep. You can do it already now with SC SetThumb.

Ok, I should have noted the Beta s first. So you ended up going with your option a) that will not survive a refresh as opposed to b) which the user could provide a map file, XYthumbsMap.txt.

I tested this out on a txt file (i.e., I assigned a image to the txt file). In looking at the associated "dat2" file for that folder, I see the non-image txt file listed in the dat2 and I assume the actual thumbnail image would be contained in the corresponding "dbits" file. It doesn't survive a refresh so the refresh overwrites the "dat2" and "dbits" files and no longer contains reference to that txt file I had assigned an image to.

1) Well, I started with the easy solution. But the other one is still good as well and I guess I will add it later.

2) Yes, the reference to that image source is not stored anywhere.

admin wrote: ↑03 Nov 2021 18:23 Yes, the reference to that image source is not stored anywhere.

Yes, I see what you mean. The file that you've associated with a thumbnail is saved (dat2) and the image itself is saved in (dbits) but the source is not saved so when you refresh both are gone.

SC setThumb would be handier for scripting though if you could provide the filename/path for the destination file(s) instead of only the currently selected file(s).

Yes, I thought about that, too. However, those files have to be among the currently listed, else it won't work. This is a bit strange for a scripting command, and it will likely generate support work.

The <xydata>\XYthumbsMap.txt thing will work in the next beta (v22.40.0204). For now I won't mention it in the change log nor elsewhere apart from here. It's an insider feature with lots of potential IMO.

Here's an example for the contents of that file: Processed from top to bottom. First match wins.
It's read just one time. When you change it you have to restart XY to catch the changes.

admin wrote: ↑03 Nov 2021 20:55 Yes, I thought about that, too. However, those files have to be among the currently listed, else it won't work. This is a bit strange for a scripting command, and it will likely generate support work.

Ahh yes, probably for the same reason we are limited to generating thumbs in the current folder only.

admin wrote: ↑03 Nov 2021 23:07 The <xydata>\XYthumbsMap.txt thing

Great!

Edit: I set up a XYthumbsMap.txt file before I even installed beta 22.40.0204 and it loaded the thumbs for the files listed in XYthumbsMap.txt when the new beta started...slick.

I would just like to add the word/tag "undocumented" (hereby done) to this thread so that it can be found more easily if a future version of myself or someone else might do a search for it.

Hey Don the thumbnail mapping using <xydata>\XYthumbsMap.txt on an XYplorer startup no longer seems to be working after the issue of v22.40.0205 which enhanced SC setThumb. I hope not intentionally. XYthumbsMap.txt does have some additional benefit over SC setThumb

By the way, it would ne nice if the syntax order was the same for each (e.g., item to set a thumb, source of thumbnail). Right now SC setThumb and XYthumbsMap.txt are opposite order. SC setThumb could be Syntax: setThumb [item], source so if item is not provided, it's the selected file. Or you could go the opposite way and reverse XYthumbsMap.txt.

I don't see at the moment why it would not work anymore, but it does not matter. I rewrote the whole thing.

In the next version you have to activate your map once:

Okay. I found out why the XYthumbsMap.txt method was not working. Currently, if you set the item thumbnail(s) using setThumb and then use the XYthumbsMap.txt method it doesn't work (i.e., thumbnails for the items do not change). If you refresh the thumbs in the folder first and then use XYthumbsMap.txt it does take affect. So essentially XYthumbsMap.txt does not override what SC setThumb has done. I figured I'd pass that on incase it somehow affects your update.