[REQUEST] generic file/entry preview

[giomatfois62]

Before opening a feature request

• I checked the next branch to see if the feature has already been implemented
• I searched existing reports to see if it is already requested.

What is the user problem or growth opportunity you want to see solved?

Currently entries can display an icon, it would be nice if this worked also for previewing text files or showing video thumbnails, like fzf-preview.

It would be even nicer if the user could provide a custom script to generate the preview (like fzf does). For example I have an RSS news reader made with rofi, when an entry is hovered it could show text or images from the web page of the article.

How do you know that this problem exists today? Why is this important?

It would improve many different use cases of rofi

Who will benefit from it?

People using rofi as file manger/chooser and many others

Rofi version (rofi -v)

1.7.5

Configuration

https://gist.github.com/Bond-009/b4b16435c6fd5f21338ccd8144a9b770

Additional information

No response

[DaveDavenport]

Is there an existing (c) library for this we can include to render the previews?
I think beside generating the icon, most code is there, for images it works:

[giomatfois62]

That's exactly the example theme I had in mind to use previews. I think something like KDE dolphin thumbnailer would be needed, to render images of many file types on the fly.
I have to research if there's something available standalone to do the job that could be integrated easily

[giomatfois62]

It seems that an all in one thumbnail generator library does not exists as of today.
What most Linux file managers do is conforming to the xdg thumbnail guidelines described here.
Thumbnails are generated by various scripts based on the file mimetype and placed in the cache directory of the user (usually HOME/.cache) named as the md5 hash of the file. The scripts are placed either in /use/share/thumbnailers or in .local/share/thumbnailers and contain the mimetypes of supported files and the command to generate the thumbnail of the input file.

I studied a bit rofi source code and what I understood is that icons in filebrowser mode are generated if the file shown is recognized to be an image or if it's a directory, while in drun mode the icon name is instead loaded from the .desktop file.

A little improvement for filebrowser mode could be to load a mimetype icon for every entry shown instead of only for directories.
For the actual file content thumbnails, the simplest solution would be to rely on the xdg spec, that is looking for a cached thumbnail in HOME/.cache and generate one if it does not exist or it is too old, using the thumbnailer scripts.
Still, this machinery is made for files and would be useful only for filebrowser mode or for displaying actual files in a dmenu script. It would be cool to have a customizable interface to generate the icons. I brought the example of the RSS reader before, another use case of mine is a list of web radio stations that I browse with rofi. Each entry has a currently unused icon url that could be fetched by a script and shown in rofi as the entry icon.

I understand that this could be very hard to implement and maybe deviate too much from the intended use cases of rofi, I would be happy to try and contibute some code if this feature is welcome.

[DaveDavenport]

Best place I think is to add it to rofi-icon-fetcher (https://github.com/davatorium/rofi/blob/next/source/rofi-icon-fetcher.c#L380).. This is what queries an internal db for the image and does an async fetch if not found.

Currently it either uses libnkutils-xdg-themes to lookup the icon, or renders a font, or tries to open it directly from the disk.
If we could add a lookup method to this, it would then be easiest to make use of it in filebrowser/recursive browser/script/dmenu mode.

F.e. we could prefix with thumbnail:// when doing the query to then try the above subscribed method?

[giomatfois62]

To keep compatibility with the xdg standard, and benefiting of cached thumbnails generated by file managers, the prefix to use should be file://. Then, the md5 hash of the path (including file://) can be used to access the thumbnail (the thumbnail filename will be <md5hash_of_path>.png).

I found a portable C md5 generator that could be included and used without licensing problems md5-c, to avoid having to link with OpenSSL.

Based on the requested size of the thumbnail, the image can be found in one of the following directories:

• $XDG_CACHE_HOME/thumbnails/normal for size up to 128x128 pixels
• $XDG_CACHE_HOME/thumbnails/large for size of 256x256 pixels
• $XDG_CACHE_HOME/thumbnails/x-large for size of 512x512 pixels
• $XDG_CACHE_HOME/thumbnails/xx-large for size of 1024x1024 pixels

If the thumbnail image is found it can be provided as icon_path to the icon_fetcher_worker, otherwise a thumbnailer script must first be triggered to generate the thumbnail, placing it in the correct folder as described above. For this we need the mime-type of the file of which the thumbnail is requested, gio method g_content_type_get_mime_type can be used for this (I see this library is already used in the codebase).

I'm dumping all these infos here as a memento for when I have some time to experiment with the code, sorry for the noise.

[DaveDavenport]

To keep compatibility with the xdg standard, and benefiting of cached thumbnails generated by file managers, the prefix to use should be file://. Then, the md5 hash of the path (including file://) can be used to access the thumbnail (the thumbnail filename will be <md5hash_of_path>.png).

That is not exactly what I wanted to say... to tell the icon fetcher to get a thumbnail, we could have a prefix so it knows what to do. It does not mean we do not follow the xdg standard for hashing and looking up.
But if it is quick, we can always lookup thumbnails, something we need to check.

[giomatfois62]

Sure let's keep it more generic with "thumbnail://", besides glib has also a method to get the encoded file URI (file://) from the filename that makes it easy to do.

Anyway i have something working, at least for fetching existing thumbnails with a fallback on mime-type icons.
In the screenshot you can see some pdfs displaying their actual thumbnail (generated by dolphin file manager) and mime icons for the rest of the files

Would you consider pull requests for this?

[DaveDavenport]

yes

[giomatfois62]

One little thing that crossed my mind while polishing the code: when fetching the mimetype thumbnail for ".desktop" files, it would be nice to instead read their "Icon=" key and display that as thumbnail.

These files are usually hidden from the user inside .local/share/applications or /usr/share/applications, and they display their icon just fine when browsed using drun mode, but in some cases (such as mine) users will keep some .desktop files on their Desktop for easy access, like is done in windows (I know, bad habits die hard), so they will be shown also in filebrowser mode.

What do you think?

[DaveDavenport]

I think that would be a nice 'extra'.

[github-actions]

This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.