Xv is an image viewer, and needs access to the entire filesystem to be able to open image files (from, for example, system icons under /usr/share/icons, cached thumbnails under $HOME/.cache and so on). The application was written in the mid-90s and doesn’t make use of any modern toolkit or desktop integration.
This specific build of xv includes Greg Roelofs’ jumbo patch collection and is built from current maintainer David Griffith’s repository with no additional patches or modifications.
ooh, ooh, next up, xmms!
While xv can open image files from anywhere, it isn’t clear why the snap can’t simply use home and removable-media like other media viewers/players. Can you detail why this needs classic?
This is indeed tricky. i have on more than one occasion wanted to just open/view a file which isn’t located in /home or /media*. Quite often I’ll want to open an image / icon file from the command line which is somewhere under /usr/share or indeed under /snap/*/current/meta/gui. If the best image viewer I have installed can’t open files, but forces me to cp them into a directory where I can view them, it’s gonna be less appealing to use.
in the case of xv, to open images outside of where confinement allows, you can do e.g.
xv - < /usr/share/icons/locolor/32x32/apps/libreoffice-calc.png
(you can test this today by doing snap install --jailmode --edge xv…)
I wish we had a way to express ‘this is how to open an arbitrary file with this’ that could work with launchers etc…
While viewing an image using data from stdin is possible (as mentioned by @chipaca), having the possibility to open the files using the application is convenient if you have a directory full of icons, thumbnails or assorted image assets. In this case you could quickly navigate through the file list or use xv’s “Visual Schnauzer”, which is actually a file manager with thumbnails.
Regarding use cases for images outside the user home or mounted media, aside from the already mentioned cases of system icons and wallpapers, snap assets, images under dot-directories (.cache, .local/share, .steam, even development assets under .android, .gradle, .rustup, .npm-global and others), there’s also the case of images served from image storage or backup volumes mounted using autofs (which would be, by default, under /net). To effectively use xv and take full advantage of its speed and convenience features (such as image navigation) to open all these kinds of files, access to the entire filesystem would be necessary.
Maybe the solution to this is via Portals?
Maybe the solution to this is via Portals?
Can’t use portals. While it would be the right solution for newer image viewers, xv’s codebase is from 1994, long before any modern desktop technology was ever dreamed of.
I wonder if such thing is implementable in a launcher, like calling a program to trigger a file open dialog and pass the snap-accessible path to the application?
I wonder if such thing is implementable in a launcher, like calling a program to trigger a file open dialog and pass the snap-accessible path to the application?
It would be possible if the application opened only a single file per run, but it’s also a file manager with filesystem navigation:
You could probably make portals work with an LD_PRELOAD.
A lot of users are going to skip the snap entirely if there isn’t a strict version. Note that portals (or even the generalized prompting work that requires no modifications to the application) wouldn’t work for files in /usr/share, because in strict mode /usr/share comes from the snap’s runtime, not the host filesystem.
At this point the requirements are understood, but as mentioned, the stated requirements are not typically a reason to grant classic confinement (eg, gimp and inkscape are not classic). @pedronis, can you weigh in?
Also, an abandoned codebase from 1994 really needs to be under strict confinement IMO…
Thanks. The code is being maintained by community members as recently as 2019 (but static code analisys reveals there’s more to fix in terms of e.g. memory access violations). I’ll investigate the feasibility and functionality of portals through LD_PRELOAD. My concern was that not having full filesystem access could disencourage use of this snap in favor of a traditionally packaged version, but you provided a good argument in the opposite direction by mentioning that users would also want a strictly confined package. It’s a quite interesting dilemma.
Thanks for this additional information.
I don’t see strong reasons to make a new precedent here