I can see that on Ubuntu 20.04 Budgie with Gimp, LibreOffice, Chromium and I guess any app’ ( my guess was totally wrong here ) using gtk-file-explorer :
On a « regular » .deb app the USB thumb would automatically appear in left pane :
Confusing behavior as some people might think they can’t access USB devices from within their snap.
Another confusing thing here the « personal folder » anyone might expect /home/$USER there but it’s actually ~/snap/app/version_number → what’s the use ?
I did not. It’s already connected by default in chromium
mount-observe is not connected in gimp nor libreoffice.
All three are connected to removable-media.
But all three show same behavior regarding connected storage devices : they don’t appear at first sight in the left pane of the file-explorer.
Of course you may access them through the « full path » /media/$USER/label_or_uuid but gtk-file-explorer provides a quicker way in regular .deb applications.
removable-media only gives you access to the mount point, mount-observe gives you additional access to the mount (and probably also plug-) events … that said, indeed the application (likely one of the xdg-portal thingies) would have to make use of this information
[ edit ] it does show up in left pane of gtk-file-explorer in chromium. I have to browse the full path ( other places, computer, /media… which is enough to lose new users ).
Gimp or libreoffice make no mention at all of mount-observe :
you might perhaps need to restart the app or re-plug the disk or some such … not sure if that would be enough and as i said above the app itself (xdg-portal-whatnot) might be missing bits and pieces here … what i want to express is that it is likely neither a chromium issue nor a snap issue in itself, the file selector comes from a xdg-portal-* deb on your system …
gimp and libreOffice simply do not have the interface defined , perhaps they should
Why don’t the gtk-file-explorer act in snap as exactly as it does in .deb ?
And I wont ever say gtk-file-explorer is ok in .deb ( no thumbnail grid view for quickly choosing pictures, a 15 years old bug ).
Back to topic : restart libreoffice or gimp, restart pc, unplug/plug usb device… it never appears at first sight in left pane.
It’s a common « report » in forums : people think snap-app can’t access usb-device because they don’t see it where they are used to expect it.
Maybe. I don’t know. Why an end-user should care about that ? All what new user sees is « when I use snap I can’t quickly find my usb-thumb ». So where to ask some help or improvement here ?
django@ASGARD:~$ dpkg -l | grep xdg
ii python3-xdg 0.26-1ubuntu1 all Python 3 library to access freedesktop.org standards
ii xdg-dbus-proxy 0.1.2-1 amd64 filtering D-Bus proxy
ii xdg-desktop-portal 1.6.0-1 amd64 desktop integration portal for Flatpak and Snap
ii xdg-desktop-portal-gtk 1.6.0-1build1 amd64 GTK+/GNOME portal backend for xdg-desktop-portal
ii xdg-user-dirs 0.17-2ubuntu1 amd64 tool to manage well known user directories
ii xdg-user-dirs-gtk 0.10-3 amd64 tool to manage well known user directories (Gtk extension)
ii xdg-utils 1.1.3-2ubuntu1.20.04.2 all desktop integration utilities from freedesktop.org
django@ASGARD:~$
Note that GIMP, being a GTK2 application, does not have access to the XDG-desktop-portal so it can only show files the snap is able to see through the confinement. I’ll experiment with the mount-observe interface to see if that helps…
There is no problem for accessing files : removable-media does its job.
The problem here is only about « where » the usb-thumb appears in gtk-file-explorer ( inside gimp, libreoffice or else ) : it appears nowhere at first sight, it should appear ( as in : should already be there ) in the left pane, exactly as it does when using same app’s ( gimp, libreoffice, chromium or else ) in legacy .deb package.
Inside snap gtk-file-explorer you have to browse the full path through :
other places → computer → /media → /$USER → /uuid_or_label_usb_thumb
The full path is needed as it also does not appear in « other places »
It’s just the « shortcut » mechanism that’s missing in the left pane, not the target resource in itself.
↑ all these at the exact same moment, usb-thumb is already mounted in expected /media/$USER/Ventoy
That’s LibreOffice on the pictures above, also GTK2 ?
Same behavior with Chromium.
You’re certainly right about XDG-desktop-portal - I dunno am just a stupid end user on desktop pc - but this « silly » regression in UI/UX exists from day one with snap’s and creates confusion.
And it’s been years long in legacy .deb app’ that gtk-file-explorer shows « mounted removable media » in that left pane.
Anyway let’s hope it’s not a « big » thing to fix and your intuition / doubt will find the answer.
I did not check how it works in flatpak - last time I checked things like pixel-saver/global-menu did not work with flatpak app’s, enough for me to lose interest. Should I test ?
Unfortunately, your instinct is right, this is a big problem to tackle. It needs one of two things depending upon which app is impacted.
For apps that use the GTK2 file picker we need GTK2 to be updated to support the desktop-portal, which is unlikely to happen considering the age of GTK2 and that we’re now onto GTK4 upstream.
For apps that use a custom file picker that they ship inside their app’s code we have less chance of fixing this because the desktop-portal doesn’t pass data about the files on your system back to the app - it only sends the actual file opened. It is possible we could implement an API to expose this data, but that is an information leak that allows the app to see beyond it’s permitted confinement boundary.
For GIMP in specific to my knowledge as the publisher of that snap the file dialogs are both GTK2 and customised within the GIMP code. So both of these scenarios apply somewhat: the file picker is customised so we have the problem of not being able to see the mounted drives’ information (mount-observe may help - I still need to make time to test that), and also GIMP is GTK2-based which means even if it weren’t using a customised file picker we’d still require GTK2 to be updated to support the desktop-portal.
The good news is that most apps using Qt5 or GTK3 should support the desktop-portal natively.
So one may wonder why gtk-file-explorer is so « late » ? Or even wonder why is there such a file picker : using system default « real » file-explorer might be enough ? ( and maybe more comfortable regarding a grid view for large thumbnails that never existed in gtk-file-explorer ? )
Or… should there be a versatile common snap-file-picker that any snap app’ could connect to /interface with ?
This is what the XDG-desktop-portal does that was mentioned earlier - there is a service that runs in every logged-in-user’s desktop session that provides a “dbus” api (a communication channel) to any app or snap that knows how to use it - when an app inside a snap calls through the snap confinement to the dbus api the service receives the call and pops up your desktop’s default file picker for you to choose any file on your system. Because the file picker ran by this service is outside of snap confinement it can see everything on your pc and behave the same way as a file picker in a non-snapped app. When you make a selection in the file picker it does a magic dance to make that file accessible to the snap that asked for the file picker to be shown.
