I was worried not to see any thumbnails for .xcf files in Nemo ( or gThumb ). Same in Nautilus, I’ve tried.
But I can see thumbnails for these files « inside » Gimp - so they do exist somewhere.
Gimp store its thumbnails in /home/$USER/snap/gimp/common/.cache/thumbnails/
It seems the user session does not look inside that folder but only in /home/$USER/.cache/thumbnails/
and Gimp as a snap won’t write therein.
Rather made of the same thought, replace ~/snap/gimp/common/.cache/thumbnails/ by a symlink targeting ~/.cache/thumbnails/ won’t work either as snap can’t acces hidden files ( even if connected to home interface ). Right ?
So I did the other way and put all my thumbnails into ~/snap/gimp/common/.cache/thumbnails/ and made a symlink ~/.cache/thumbnails/ targeting ~/snap/gimp/… and yes it works but 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.
Here what happens now in gThumb :
.xcf thumbnails are also used in a lower quality though [ below ] but the picture itself is empty [ above ].
So here are the questions :
⋅ I presume there’s a better way to achieve that ( .xcf thumbnails in file explorer ) any suggestion ?
⋅ thumbnails made by gimp snap for .xcf files should be available to any app’s user side. Is there a way to allow that ?
⋅ how tell my session to look for thumbnails not only in ~/.cache/thumbnails/ but also in any thumbnails folder inside ~/snap/ ?
⋅ gThumb. Well maybe it’s unable to display .xcf files at all. Do you know ?
Gimp displaying XCF thumbnails in its own file dialog
gThumb not being able to display XCF files
(2) is explained by Gimp customising the GTK file chooser to include a preview pane that uses the Gimp code to generate the previews.
For (1), there’s two ways Nautilus can display a thumbnail:
If a valid thumbnail is available in ~/.cache/thumbnails, that will be used.
Check if a thumbnailer executable is registered for the mime type in /usr/share/thumbnailer. If so, run it and save the result to ~/.cache/thumbnails
Gimp supports the first case, writing out a thumbnail when saving a file. It has never done the second, so e.g. thumbnailing of an XCF file downloaded from the web has never worked.
As you’ve noticed, the the first method is broken with the snapped version of Gimp at present, as it can’t write to (or even access) ~/.cache/thumbnails. Unfortunately, there isn’t a safe way to do this at present without allowing snaps to learn about or replace files they cannot access.
For (3), gPhoto is likely using the gdk-pixbuf library to load images. There is an old loader module for XCF files, but it likely doesn’t support the most recent versions of the file format, and is not usually installed. I don’t think you should expect this to work, even in the absence of snaps.
Nemo, Nautilus and others can display those thumbnails generated by Gimp, only problem here is their location.
If
django@ASGARD:~/.cache$ ls -la
(…)
lrwxrwxrwx 1 django django 47 juin 11 02:47 thumbnails -> /home/django/snap/gimp/common/.cache/thumbnail
then
any app can use those thumbnails for .xcf
hence
1⋅ 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 the issue for any snap app eventually generating thumbnails.
2⋅ reading again snap doc I wonder if https://snapcraft.io/docs/thumbnailer-service-interface might be the answer. Should I connect that interface to Gimp ? ( after I get back to initial situation regarding thumbnails folders ) Or doesn’t it do what I’m looking for ? if it does then that interface should be connected by default to the snap package.see below
My actual setup is not desirable : all my user’s thumbnails are in a subfolder of Gimp which does not make sense, only for having .xcf thumbnails displayed in any app.
later :
django@ASGARD:~$ sudo snap connect gimp:thumbnailer-service
erreur : snap "gimp" has no plug named "thumbnailer-service"
django@ASGARD:~$
so it answers 2⋅ and lets 1⋅ as the only thing I can think of.
3⋅ 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 ?
It’s unlikely that it would be granted. If it was safe to give strict confined applications to the user’s thumbnail cache, then we’d probably grant that access through the desktop interface.
Some examples of why include:
Each of the PNG thumbnails in ~/.cache/thumbnails includes the full path name of the file it represents. This would give the confined application information about the file system it wouldn’t otherwise have.
The thumbnail images will reveal information about files the app cannot access.
The application can replace the thumbnails of arbitrary files (including files it cannot access), which could be used to mislead the user in some way.
So how do I tell Ubuntu to look for thumbnails in usual ~/.cache/thumbnails + in ~/snap/gimp/common/.cache/thumbnails/ ? Or in any folder named thumbnails inside ~/snap/ ?
If I were using Gimp as a .deb it would store these thumbnails in the usual place…
If snap-gimp can’t change where it stores them, then Ubuntu should change where it looks for them.
That would still leave you open to (3). Granted it would be some somewhat more limited, since you could only provide thumbnails for files you know the modification time of.
Adding support for on demand thumbnailing (i.e. handlers registered in /usr/share/thumbnailers) by confined apps is more tractable, since it has well defined inputs and outputs. The existing “sandboxed thumbnailer” model in Nautilus shows how this could be done. In particular you want to prevent the thumbnailer from writing to the filesystem or communicating with other processes or the network, to prevent exfiltration of the file data.
This wouldn’t help with current software releases though, since (a) Gimp doesn’t provide an on demand thumbnailer for XCF files, and (b) libgnome-desktop would need to recognise Snap confined thumbnailers and not try to run them under bwrap.
Why such a simple, useful thing as thumbnails have to become so hard to handle ?
Please walk in some nonIT-nonDev-user shoes. What shall s⋅he think ?
Gimp-as-a-deb → thumbnails for .xcf files are visible in Nautilus, Nemo, Gimp and others → good.
Gimp-as-a-snap → thumbnails are visible nowhere, only in Gimp → not as good, even bad if you spent many hours a day editing pictures.
I’m glad you’re trying to explain to me the mechanics behind but I still wonder why I can’t tell my Ubuntu to look for thumbnails not only in ~/.cache/thumbnails but also in ~/snap/…/…/thumbnails ?
It may happen that Gimp won’t be the only app’ to generate its own thumbnails ?
because snap security is complex.
doing it with a proper implementation instead of some gross hack that allows some snap packager to abuse a zero day security flaw in the hosts thumbnailer to steal your banking passwords via a manipulated thumbnail is not actually trivial …
Not gnome. It will be the same in any DE. Something to change in Ubuntu, yes probably, after all it has same mother as snap and should give the best example for advocating snap.
I want to fix what was not broken before using Gimp as a snap. Make it as comfortable of use as it was before. I’m pretty sure we’re not far since it’s just a matter of folder location.
Gimp-snap won’t ever write into ~/.cache/thumbnails so let’s try the other way round : make DE or system « aware » there are thumbnails to look up also in ~/snap/…/…/thumbnails
How do you plan to achive that ? It isnt like dolphin and nautilus (pcmanfm, gnome-commander, nemo, you name it) use the same thumbnailer … if you want to teach them all about ~/snap that means getting all of them fixed …
There is no longer thumbnailer for .xcf files in 20.04.
And whatever thumbnailer used, they store their .png into ~/.cache/thumbnails
Gimp ( snap or deb ) generates itself these thumbnails, therefore only for local files, deb will store them into the usual previous place, and snap into ~/snap/gimp/…
Do you feel coming in the ugly workaround I tried ?
I copied all of my user’s thumbnails into ~/snap/gimp/common/.cache/thumbnails/
Then made ~/.cache/thumbnails a symlink targetting ↑
Everything was OK : .xcf thumbnails in Nemo, Nautilus, gThumb, and Gimp of course. And OK too for thumbnails of other types ( music, video, etc ).
It is just very weird to have all of an user’s thumbnails into a subfolder of a specific snap…
So I imagined there was maybe a way to modify how thumbnails are « collected », a bit like a $PATH for thumbnails to concatenate many locations.
Implies maybe a /snap/common/.cache/thumbnails which any installed snap could share ( I guess this goes against confinement, yet it sits under ~/snap ).
I’m a dreamer, not a dev’ so I don’t know.
But I know for sure as a user I appreciate having thumbnails for .xcf in file explorer⋅s.
That interface was written to support one of the services that made up the Unity 8 user interface on Ubuntu Phone. You can find the source code for the backend service here:
It does not implement the FD.o Thumbnailer spec, instead providing a D-Bus interface allowing clients to request a thumbnail for a particular file name, and receive the image data in response. It used AppArmor to determine whether the client was able to read the file it was requesting access to, but we never finished making it fully compatible with snaps. The design goal was to provide a shared thumbnail cache without providing an oracle into the rest of the system to confined apps.
The service was also limited to its built-in thumbnailing routines:
images: anything supported by gdk-pixbuf
videos: anything supported by GStreamer, extracting a frame part way into the video
audio: extract cover art from MP3s, MP4s, and various ogg formats via taglib.
