Gimp as a snap ⋅ no thumbnails for .xcf files in Nemo, gThumb…

Hi,

references :
https://forum.ubuntu-fr.org/viewtopic.php?id=2053949 [ french ]
https://forum.snapcraft.io/t/gimp-and-thumbnails-for-xcf-files/18131 [ english, more or less ]

tl;dr

when using Gimp as a snap, you’ll see thumbnails for .xcf files only « inside » Gimp and nowhere else ( Nemo, Nautilus, gThumb… )

I did a messy workaround for .xcf thumbnails to appear anywhere expected : I put all of my user’s thumbnails into ~/snap/gimp/common/.cache/thumbnails/ and now ~/.cache/thumbnails/ is a symlink targeting the first.

You’d agree it’s absolutely a bad idea to store all of an user’s thumbnails into a particular subfolder of a particular snap.

So any suggestion to achieve that in a better way is welcome :wink:
⋅ how tell my session to look for thumbnails not only in ~/.cache/thumbnails/ but also in any thumbnails folder inside ~/snap/ ?

Snap… see, I try to use them but it’s not painless.


later :

django@ASGARD:~$ sudo snap connect gimp:thumbnailer-service
erreur : snap "gimp" has no plug named "thumbnailer-service"
django@ASGARD:~$

@bashfulrobot ⋅ is personal-files interface of any help in this situation ?
I just don’t understand if I can set it myself, and how, or if it needs first be enabled package’s side ?


…then gimp-snap may use ~/.cache/thumbnails instead of ~/snap/gimp/… for storing the thumbnails it generates ?

This is something that the snap author has to define. Then you actually apply to use the interface (post on the forum) due to the security implications. And testing, etc.

Ok now I understand, thanks.

So best way would be an answer to :
⋅ how tell my session to look for thumbnails not only in ~/.cache/thumbnails/ but also in any thumbnails folder inside ~/snap/ ?
Then it would solve this issue, and for any snap generating thumbnails.

If I follow you correctly, any location or file that you want to access needs to be defined within the interface. And they can be defined as read only or read and write.

Errr… I was meaning without modifying anything snap side. Some system settings regarding how thumbnails are searched.

Isn’t it surprising that any app looks only in ~/.cache/thumbnails ?

Is there a way to « expand » that search to either :
⋅ any folder named thumbnails inside ~/ including therefore those in ~/snap
⋅ or defining many paths like ~/.cache/thumbnails + ~/snap/gimp/common/.cache/thumbnails/ + others if needed ?

Where does Ubuntu define paths for thumbnails folders ? And how « aggregate » those ?

Another trick maybe… automatically add to ~/.cache/thumbnails the files found in ~/snap/gimp/common/.cache/thumbnails/ as soon as they’re created or modified ?
I can’t do that with a symlink… The fusion of 2 folders, sort of.

Ah - if the behaviour of the application (search paths, functionality, etc) needs to be changed - that would be outside the packaging and in the source code itself upstream.

If an app does only look in ~/.cache/thumbnails, there could be a reason the author decided to do that - be it a standard or anything else…

Well I think the reason is any lib-thumbnailer sends its .png to ~/.cache/thumbnails which is good.

Now can’t it be a kind of $PATH to « concatenate » many thumbnails folders ?

This only because some snap app’s will never send their .png thumbnails to ~/.cache/thumbnails
it’s Gimp here but maybe there could be others… Gimp as deb sends its thumbnails to the ↑ usual place.

Workaround in the other way.

Put inside
~/.cache/thumbnails/normal/
a symlink to the thumbnails stored by gimp-snap

lrwxrwxrwx 1 django django     54 août   2 01:08 xcf_normal -> /home/django/snap/gimp/common/.cache/thumbnails/normal

Now thumbnails for xcf do appear in nemo and others…

Perhaps offtopic, but why would you want to use the snap version of Gimp?

Because snap is 2.10.20 and will keep improving as soon as possible.

In APT repo it’s 2.10.18 for Ubuntu 18.04 and 20.04.

And once you worked some xcf files in 2.10.x you can NOT go back to 2.8.x - no backward compatibility (!) if I had known…
so easier way to install 2.10.x also in Ubuntu16.04 is snap ( no ppa / AppImage and FlatPak do not fit well with Unity ).

Yeah at work I still rely on 16.04 - actually no DE beats Unity ( dual monitors ) and I don’t know yet what I’ll do in April '21.

And these last months, each new version of Gimp brought some little or big new things or fixes I happen to need or appreciate…

I guess Gimp’s dev’s prefer FlatPak over Snap, but I do prefer « global menu » rather than stacking horizontal bars on top of my screen. Only Snap handles it.

Beside these reasons I really think both Snap and FlatPak are a pain to manage for « average » users. There’s a lack of fancy full-featured graphical tool to manage them. There’s a lack of self-explanatory « prompts » to guide users towards sane settings and a lack of features discoverability ( saved snapshots / versions )…

Oh I thought there was an AppImage for it.
I install AppImageLauncher. It integrates AppImages like DigiKam automatically (and moves them to an app folder) and works fine with Panel, Icon Task List.

I thought everything you install via Snap is very slow to start up… and I thought Snap would die soon…

Is this security also an issue for the flatpak GIMP I have installed? When I went to the GIMP download page, it specifically listed flatpak as the top choice for install, and I currently have 2.10.20 (unlike macOS, stuck at 2.10.14…grrrr!) I’m going to look into it right now :slight_smile:

OH, you’re right the Global menu doesn’t integrate, why did I not see that?
Nemo does show an .xcf file on the desktop, but only as a generic image with a faint Gp on it. Same as .kra files from my flatpak Krita - heeey! What the heck? I guess flatpak devs just figure you should know where your stuff gets saved to?

Indeed there’s an AppImage for Gimp …but it does not send menu to global-menu applet in Budgie or Unity. And not sure that Gimp-AppImage will warn me when a newer version is available ( I know some AppImage do ).

I can’t speak for every thing :wink: but on my machines gimp-snap starts fast. I mean fast enough for me not needing to compare with .deb or other package.
My system / + my personal ( hidden ) config’ files are on the same partition of SSD.
Only my personal ( non-hidden ) files are on another HDD.

Snap-slowness may be related to /home/$USER treated as a separate partition on a slower disc than the root system. Personal config’s for snap-app’s are stored in ~/snap so I guess it’s better to keep those on the fastest disc ???

Probably the same joke in Flatpak as in Snap :
thumbnails generated by krita-flatpak or gimp-flatpak can’t be written down to
~/.cache/thumbnails/normal
because of sandboxing / confinement, and then are rather stored in
~/.var/app/<app-id>/cache/thumbnails/… ???

The symbolic-link trick might also work, let us know :wink: